Closed Bug 1182644 Opened 9 years ago Closed 9 years ago

[Bluetooth] When transferring a file to laptop, device restarts upon completion of transfer.

Categories

(Firefox OS Graveyard :: Gaia::Bluetooth, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.5+, b2g-master affected)

RESOLVED DUPLICATE of bug 1191715
blocking-b2g 2.5+
Tracking Status
b2g-master --- affected

People

(Reporter: NicholasN, Unassigned)

References

()

Details

(Keywords: regression, Whiteboard: [2.5-Daily-Testing][Spark])

Attachments

(1 file)

Attached file logcat_bluetooth.txt (deleted) —
Description: The user pairs the device to a laptop via bluetooth, then shares any file. Right as the transfer completes successfully, the device appears to reboot. Sometimes the just goes black and returns to the lock screen when the power button is tapped. Other times the screen goes black, the blue firefox OS screen appears, and then the lock screen comes up. This does not occur device to device, only device to laptop. Repro Steps: 1) Update an Aries to 20150710105517 2) Enable bluetooth and pair to a laptop. 3) Open any file that can be shared, and share via bluetooth to the laptop. 4) Open the notification tray and observe transfer. Actual: Device reboots just as the transfer completes successfully. Expected: Device does not reboot after transfer. Notes: Environmental Variables: Device: Aries 2.5 Build ID: 20150710105517 Gaia: ad76c159c641c977d9140c5fedea84aea04e0e60 Gecko: f7e1f596d57d Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd Version: 42.0a1 (2.5) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0 Repro frequency: 6/6 See attached: video clip, logcat
This issue does not occur in Flame 2.5 or the RC4 build of AriesKK. It appears to be a recent regression in Aries. Flame 2.5 Actual Result: Bluetooth transfer completed and the phone did not reboot. Environmental Variables: Device: Flame 2.5 BuildID: 20150710010203 Gaia: ad76c159c641c977d9140c5fedea84aea04e0e60 Gecko: 2c91d57441fd Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4 Version: 42.0a1 (2.5) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0 AriesKK 2.5 (RC4 Build) Actual Result: Bluetooth transfer completed and the phone did not reboot. Environmental Variables: Device: Aries 2.5 BuildID: 20150619225606 Gaia: 4c06ed88ddccaba8dc941e5006bd2a9e57306f07 Gecko: 7c1a6b1151a1539186b950a144387e2d7f378d1b Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd Version: 41.0a1 (2.5) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: regression
Summary: [Bluetooth] Device restarts after file transfer completes. → [Bluetooth] When transferring a file to laptop, device restarts upon completion of transfer.
Whiteboard: [2.5-Daily-Testing][Spark]
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.5?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga)
Summary: [Bluetooth] When transferring a file to laptop, device restarts upon completion of transfer. → [Aries][Bluetooth] When transferring a file to laptop, device restarts upon completion of transfer.
The changes for Bug 1155059 seem to have caused this issue. Mozilla-inbound Regression Window Last Working Environmental Variables: Device: Aries 2.5 BuildID: 20150710034840 Gaia: ad76c159c641c977d9140c5fedea84aea04e0e60 Gecko: 3871596b6370 Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd Version: 42.0a1 (2.5) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0 First Broken Environmental Variables: Device: Aries 2.5 BuildID: 20150710035707 Gaia: ad76c159c641c977d9140c5fedea84aea04e0e60 Gecko: 470d574f3f49 Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd Version: 42.0a1 (2.5) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0 Last Working gaia / First Broken gecko - Issue DOES occur Gaia: ad76c159c641c977d9140c5fedea84aea04e0e60 Gecko: 470d574f3f49 First Broken gaia / Last Working gecko - Issue does NOT occur Gaia: ad76c159c641c977d9140c5fedea84aea04e0e60 Gecko: 3871596b6370 Gecko Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3871596b6370&tochange=470d574f3f49
Blocks: 1155059
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Randell, can you take a look at this please? This might have been caused by the work done for bug 1155059. This is a smoke test blocker.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(rjesup)
This issue is now seen occurring on Flame devices with the latest 2.5 build. Device reboots just as the transfer completes successfully. Environmental Variables: Device: Flame 2.5 Build ID: 20150713010204 Gaia: e4b63559eba364892867eb381c3002d6518e5d6a Gecko: eab21ec484bb Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4 Version: 42.0a1 (2.5) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0
Summary: [Aries][Bluetooth] When transferring a file to laptop, device restarts upon completion of transfer. → [Bluetooth] When transferring a file to laptop, device restarts upon completion of transfer.
Flagging the reviewers of bug 1155059 to take a look initially, instead of backing out the bulk of commits, this is a smoketest blocker.
Flags: needinfo?(nfroyd)
Flags: needinfo?(jdaggett)
Flags: needinfo?(cpearce)
I suspect this has tripped an existing bug, perhaps timing. I've already found several instances of "don't know which thread something will release on" with runnables while working on converting directories over to already_AddRefed. Is this a)crashing the device, or b) forcing gecko/gaia to restart? Can you attach with GDB and catch the crash? Can you tell me how to reproduce this locally? I have Flame devices, though they need updating.
Flags: needinfo?(rjesup) → needinfo?(nnelson)
Also, is it possible to run this in a debug build? Yes, I know it'll be slow...
Requesting qawanted to assist with Comment 7 and Comment 8
Keywords: qaurgent, qawanted
Looks like there's no taskcluster debug aries builds anymore, I'll have to follow up with taskcluster team. There's debug builds for flame : https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/tinderbox-builds/mozilla-central-flame-kk-eng-debug/
It happens on flame, Naoki provided the debug builds. Currently not set-up to connect with GDB locally here. The device rebooted and didn't provide a crash report. Attachment 8632271 [details] has the adb logcat To produce it locally, have a laptop with bluetooth enabled: 1. Connect Flame to laptop 2. From Gallery send picture to laptop Actual Flame reboots after sending (file is received by laptop).
Flags: needinfo?(nnelson) → needinfo?(rjesup)
I think this is an issue unrelated to the fontloader changes that I reviewed.
Flags: needinfo?(jdaggett)
I downloaded the latest build from and flashed flame-kk.zip (./flash.sh) Turned on Bluetooth, made visible. Paired from laptop and phone. Laptop (Win7 W520) installed most drivers (first two failed). Took picture on Flame. Viewed it, hit the share icon. Selected Bluetooth & the laptop. File transfered, saw notification it was done. No crashes. Any steps missing? The base build on this flame is likely old.
Flags: needinfo?(rjesup)
Flags: needinfo?(nnelson)
Flags: needinfo?(nhirata.bugzilla)
We are testing in a Linux environment using Ubuntu 12.04. I was able to reproduce this on the latest flame build we have with those same steps. Environmental Variables: Device: Flame 2.5 BuildID: 20150714010206 Gaia: 7676b68b4d32ed13243eeb719188847121bd5611 Gecko: 0931671a14ef Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4 Version: 42.0a1 (2.5) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0 You can find the latest base here: https://developer.mozilla.org/en-US/Firefox_OS/Phone_guide/Flame/Updating_your_Flame#Up-to-date_%28use_these_unless_you_have_a_good_reason_not_to%29
Flags: needinfo?(nnelson)
Just as a side follow up : Bug 1184336 for the Aries debug builds. Wait. If Randall can't reproduce with an old gonk layer and we can reproduce with a newer gonk layer, doesn't that mean the issue is in the gonk? Randall, could you please update your flame's gonk layer and retest to see if you can reproduce? Direct link to the build : http://cds.w5v8t3u9.hwcdn.net/v18D_nightly_v3.zip
Flags: needinfo?(nhirata.bugzilla) → needinfo?(rjesup)
Flags: needinfo?(cpearce)
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #15) > Just as a side follow up : Bug 1184336 for the Aries debug builds. > > Wait. If Randall can't reproduce with an old gonk layer and we can > reproduce with a newer gonk layer, doesn't that mean the issue is in the > gonk? > > Randall, could you please update your flame's gonk layer and retest to see > if you can reproduce? > Direct link to the build : http://cds.w5v8t3u9.hwcdn.net/v18D_nightly_v3.zip Flashed 18D_nightly_v3 (which says it's v5 in the zip file...) Softwar/OS Version (in Device Information) used to say 2.5.0.0-prerelease, now it says 3.0.0.0-prerelease. This installed a 5/27 Gecko; this also worked. ( I then installed the newer gecko per above (7/13). This won't boot; I'm seeing this: F/MOZ_Assert( 1245): Assertion failure: timestamp <= PR_Now(), at /builds/slave/b2g_m-cen_flm-kk_eng-d_dep-000/build/gecko/dom/quota/QuotaManager.cpp:3324
Flags: needinfo?(rjesup) → needinfo?(nhirata.bugzilla)
That's https://bugzilla.mozilla.org/show_bug.cgi?id=1110010 This shouldn't cause the phone not to boot. You have to have the matching gecko/gaia versions together in order for it to boot correctly. It may be easier to do a full flash of the device once you flashed the contributor build.
Flags: needinfo?(nhirata.bugzilla) → needinfo?(rjesup)
(In reply to Randell Jesup [:jesup] from comment #16) > (In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from > comment #15) > > Just as a side follow up : Bug 1184336 for the Aries debug builds. > > > > Wait. If Randall can't reproduce with an old gonk layer and we can > > reproduce with a newer gonk layer, doesn't that mean the issue is in the > > gonk? > > > > Randall, could you please update your flame's gonk layer and retest to see > > if you can reproduce? > > Direct link to the build : http://cds.w5v8t3u9.hwcdn.net/v18D_nightly_v3.zip > > Flashed 18D_nightly_v3 (which says it's v5 in the zip file...) > Softwar/OS Version (in Device Information) used to say 2.5.0.0-prerelease, > now it says 3.0.0.0-prerelease. This installed a 5/27 Gecko; this also > worked. ( > > I then installed the newer gecko per above (7/13). This won't boot; I'm > seeing this: > > F/MOZ_Assert( 1245): Assertion failure: timestamp <= PR_Now(), at > /builds/slave/b2g_m-cen_flm-kk_eng-d_dep-000/build/gecko/dom/quota/ > QuotaManager.cpp:3324 This should be fixed if you perform 'make reset-gaia' in the gaia folder.
Jesup could not reproduce on windows, I could not reproduce on Mac nor Linux using debug build, asked PBylenga and his team to reinvestigate.
Flags: needinfo?(pbylenga)
I can believe that bug 1155059 turned up some issues; I don't think I have anything useful to contribute here, though.
Flags: needinfo?(nfroyd)
I was able to reproduce this issue using a debug engineering build when transferring to both an Ubuntu laptop, and a Windows 7 laptop. Environmental Variables: Device: Flame 2.5 (Full Flash) Build ID: 20150721073213 Gaia: 4fe0507781f3ed56c8ae5e66dd9489165d1ff68e Gecko: d7a9e44717b7 Gonk: 41d3e221039d1c4486fc13ff26793a7a39226423 Version: 42.0a1 (2.5) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0
Flags: needinfo?(pbylenga)
(In reply to Martin Shuman [:Marty] from comment #21) > I was able to reproduce this issue using a debug engineering build when > transferring to both an Ubuntu laptop, and a Windows 7 laptop. Where can I install this exact version from? > > Environmental Variables: > Device: Flame 2.5 (Full Flash) > Build ID: 20150721073213 > Gaia: 4fe0507781f3ed56c8ae5e66dd9489165d1ff68e > Gecko: d7a9e44717b7 > Gonk: 41d3e221039d1c4486fc13ff26793a7a39226423
Flags: needinfo?(rjesup) → needinfo?(pbylenga)
Flags: needinfo?(pbylenga) → needinfo?(rjesup)
I also should note we used the flame-kk.zip to full flash.
Flashed that build. Couldn't pair (many attempts), rebooted, wouldn't boot (known assertion issue). did reset-gaia, tried again. *Many* pairing attempts later it *finally* paired (it wouldn't show the code/UX with Pair button). Transferred photo from camera. No crash. Tried transferring from Gallery as well, no crash. I'm stuck until someone can get a log from a crashing phone (that shows the crash) at least or better yet reproduce it in gdb.
Flags: needinfo?(rjesup)
Flags: needinfo?(pbylenga)
Flags: needinfo?(nhirata.bugzilla)
Given that the dev and I are having a hard time reproducing the issue, could we get a video of the reproduction? I think there's some step missing.
I'm not sure if this matters, which side initiated the connection? Also which module is on the linux box itself to support the blue tooth transfer?
(In reply to Randell Jesup [:jesup] from comment #25) > Flashed that build. Couldn't pair (many attempts), rebooted, wouldn't boot > (known assertion issue). did reset-gaia, tried again. *Many* pairing > attempts later it *finally* paired (it wouldn't show the code/UX with Pair > button). Transferred photo from camera. No crash. Tried transferring from > Gallery as well, no crash. > > I'm stuck until someone can get a log from a crashing phone (that shows the > crash) at least or better yet reproduce it in gdb. This sounds like issues we used to see on an older Gonk, can you update base image before flashing? (In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #26) > Given that the dev and I are having a hard time reproducing the issue, could > we get a video of the reproduction? I think there's some step missing. There's a video already in the URL section (In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #27) > I'm not sure if this matters, which side initiated the connection? > > Also which module is on the linux box itself to support the blue tooth > transfer? We've done both for initiation (starting at laptop and phone) We're using a bluetooth dongle: http://www.iogear.com/product/GBU521/
Flags: needinfo?(pbylenga)
Marked as 2.5+, it's pretty serious which need to be fixed
blocking-b2g: 2.5? → 2.5+
Ok: differences in the video from what I did (and I presume naoki did): a) it's not a Flame, though according to the comments here it happens to Flames as well now. (ok) b) it's a video, not a still image (dunno if it matters). ALso, it was done via the Video app, not the camera. Initial report says "any file that can be shared". c) most of my tests were from viewing the items, not from the list of items (and typically from viewing the picture from the camera app, though I tried the gallery once too out of paranoia). d) the notification bar was pulled down to watch the transfer. I just started it and waited So I tried this (on a Flame), as close as I could. No crash. NI to nhirata. I'm out of ways to look at this without someone getting some more data. I'll note there are a TON of Dispatch/DispatchToMainThread in bluetooth, and typically they were done in a way that was not threadsafe (the Release() might happen on MainThread, or on the sending thread, depending on timing) - and most are still that way until followup patches land, but there may be minor timing or other differences that affect which thread or exactly when it's destroyed (which this API change is meant to help us resolve to get reliable behavior). There are patches to move to reliable Dispatch semantics for bluetooth (untested) on a bug now with a ton of other patches
I suspect the dongle. The bluetooth device is a v4 bluetooth. I only have v2 devices. Can you try to reproduce this issue with v2 bluetooth machine/device instead if there's a machine available such as that? I will see about a v4 bluetooth dongle.
Flags: needinfo?(pbylenga)
I attempted to pair the Aries to my Ipad Mini (which uses v2 bluetooth). Unfortunately I was unable to do so and consistently kept receiving a "Unsupported format" message. Tomorrow we will have access to a Surface Pro V3 tablet and will be attempting with a V4 bluetooth connection. Environmental Variables: Device: Aries 2.5 BuildID: 20150727165113 Gaia: 302a448729ff2b336581cf94b66327ea836294c7 Gecko: d576f2cec511 Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd Version: 42.0a1 (2.5) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
I tested this on Flame 2.5 and Aries KK, connecting to a V4 bluetooth device (Windows laptop). In both instances the file failed to send just after initiating the transfer. 4/4 repro attempts. Aries KK Actual Result: File fails to send right after transfer begins. Environmental Variables: Device: Aries 2.5 BuildID: 20150729131820 Gaia: 302a448729ff2b336581cf94b66327ea836294c7 Gecko: cd9fa05c943e6784faeeaff7c027d1b561c070b0 Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd Version: 42.0a1 (2.5) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0 Flame 2.5 Actual Result: File fails to send right after transfer begins. Environmental Variables: Device: Flame 2.5 BuildID: 20150729030209 Gaia: 21256d7665f972255d198f8af81a8df4bd0e0fc4 Gecko: 2ee9895e032c Gonk: 41d3e221039d1c4486fc13ff26793a7a39226423 Version: 42.0a1 (2.5) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0
Blocks: 1174840
clearing NI, leaving qawanted to try to get a gdb log
Flags: needinfo?(pbylenga)
Nick can you write up a new issue for the instances where we failed to pair.
Flags: needinfo?(nnelson)
Here is the bug for the V4 issue I mentioned above. https://bugzilla.mozilla.org/show_bug.cgi?id=1189521
Flags: needinfo?(nnelson)
Odd. I thought I updated this bug last friday. Anyhow, the v4 BT dongle seemed to work for me on the windows machine. I think it's that specific version of the adapter that's the issue. I think we'll need an iogear v4 bt adapater.
Flags: needinfo?(nhirata.bugzilla)
Flags: needinfo?(nhirata.bugzilla)
Demoting as a smoke test blocker given it may be specific to certain hardware configurations. Still a major issue.
Keywords: smoketest
Hi Ben, does this bug have the same root cause with bug 1189521?
Flags: needinfo?(btian)
(In reply to Ken Chang[:ken] from comment #39) > Hi Ben, does this bug have the same root cause with bug 1189521? I don't think so. This bug's symptom is crash, while bug 1189521 only shows error and happens on Surface only.
Flags: needinfo?(btian)
I still cannot reproduce the original issue of the reboot after sending the file. When I send the file from the device, it cancels it automatically. When I send the file from the computer, the image is sent without reboot. I don't think this issue exists any more. Comment 33 also doesn't specify that the original issue is being seen. I think we need to close this out as WFM and open a new one in regards to the device not sending.
Flags: needinfo?(nhirata.bugzilla) → needinfo?(nnelson)
To note, I used Ubuntu + the iogear BT v4 adapter. I should be using the same configuration as per the reporter.
The bug symptom seems similar to bug 1191715 since the crash happens during disconnection. qawanted to confirm whether this bug remains on the latest m-c since bug 1191715 fix is already landed.
Following the repro steps in description, I did not observe any issue on the latest master build. Files transferred to laptop successfully. Build ID 20150909215153 Gaia Revision 47459eead04385e22f967012b824f5abdddcfb7c Gaia Date 2015-09-09 10:37:28 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/dd2a1d737a64d9a3f23714ec5cc623ec8933b51f Gecko Version 43.0a1 Device Name aries Firmware(Release) 4.4.2 Firmware(Incremental) eng.worker.20150909.211310 Firmware Date Wed Sep 9 21:13:17 UTC 2015 Bootloader s1
Resolve duplicate per comment 44. Please reopen this bug for any further concern or if it reoccurs.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
This issue is no longer occurring on the the latest Flame and Spark 2.5 Master builds. The bluetooth transfer completes successfully, and the device does not crash or restart afterwards. I did try this on a 9/8 Flame build from a couple days ago, before the fix for bug 1191715, and the issue was still occurring, so I would agree that this is a dupe of that bug. Removing qaurgent and qawanted tags. Environmental Variables: Device: Aries 2.5 BuildID: 20150909215207 Gaia: 47459eead04385e22f967012b824f5abdddcfb7c Gecko: dd2a1d737a64d9a3f23714ec5cc623ec8933b51f Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd Version: 43.0a1 (2.5) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0 Environmental Variables: Device: Flame 2.5 BuildID: 20150910030223 Gaia: 47459eead04385e22f967012b824f5abdddcfb7c Gecko: dd2a1d737a64d9a3f23714ec5cc623ec8933b51f Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd Version: 43.0a1 (2.5) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(nnelson) → needinfo?(jmercado)
Keywords: qaurgent, qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmercado)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: