Closed Bug 1142747 Opened 7 years ago Closed 3 years ago
[Accessibility] crash during Fx
A login with screen reader on - crash in mozilla::CDMCaps::Lock()
This bug was filed from the Socorro interface and is report bp-61a8dd82-2b65-46a8-a021-83a3e2150312. ============================================================= I encountered this crash with the following STR: Repro Steps: 1) Update a Flame to 20150312010235. 2) Enable Screen Reader on Settings > Accessibility. 3) Go to Settings > Firefox Accounts > Create Account or Sign In. 4) Enter an email address, and select Next. 5) Tap on the password input field to enter password. Actual: The crash occurs, and the device restarts. Expected: The user is able to log in without any issues. Device: Flame Master (KK, 319mb, full flash) Build ID: 20150312010235 Gaia: 0c4e8b0b330757e261b031b7e7f326ef419c9808 Gecko: 5334d2bead3e Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429 Version: 39.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0 Repro Rate: 1/5 Due to the low repro rate, I am currently unable to provide a logcat or other media files.
QA Whiteboard: [QAnalyst-Triage?]
QA Whiteboard: [QAnalyst-Triage?]
I spent about an hour on the latest Nightly 3.0 build without the phone crashing with screen reader on and logging into FxA. I tried using wifi/data, high and low memory situations, logging in after a fresh flash. No repro after 20 login attempts. Leaving the tags for others to try to find steps. Environmental Variables: Device: Flame 3.0 BuildID: 20150313010238 Gaia: eabe35cf054d47087b37c1ca7db8143717fbd7f3 Gecko: 42afc7ef5ccb Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429 Version: 39.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0
I encounter a different crash when attempting the repro steps. The following crash occurred when I was on the email entering page (step 4 of original STR), I had my keyboard invoked, and the device rebooted as soon as I double tapped on the enter button on the keyboard. https://crash-stats.mozilla.com/report/index/26e5a42f-f316-473f-a14f-3f2f42150313 The following similar crash occurred when I simply double tapped on the email field to invoke the keyboard: https://crash-stats.mozilla.com/report/index/7629f8e3-548d-4557-9d16-5f6d82150313 Attached is the logcat of the abovementioned 2nd crash. I wasn't able to reproduce the original crash after one hour of trying though. And these 2 crashes I encountered seem to be random as well.
It looks like the two crashes you encountered are the same. Can you write this up separately?
Flags: needinfo?(ktucker) → needinfo?(pcheng)
Naoki, can you please take a look at this crash i got today while trying to reproduce this bug: https://crash-stats.mozilla.com/report/index/2c78b933-7777-4f61-a750-906a52150407 Also, the 2 in Comment 2 may be the same as well. My steps are: 1. Turn on screen reader. 2. Go to Firefox Accounts in settings. 3. Tap sign in and enter an email address. 4. Start typing a password on the next page and then tap "Back". 5. Tap the home button to go home. 6. Go back into settings and tap on Wi-Fi. 7. Tap on an available wifi connection and start typing in a password. Actual: A crash will occur while typing on the keyboard.
associating the crash with the symbols
Odd. I don't think the crash associated with the symbols correctly... Also to note, I think it may have crashed at the driver level? Not sure if I was reading this correctly.
corrected crashdump association.
Attachment #8589338 - Attachment is obsolete: true
It's the same crash.
Removing steps-wanted since I can get this crash to occur fairly consistently with the steps in Comment 5.
Component: Disability Access APIs → WebRTC: Audio/Video
QA: Is this still happening? Paul, can you take a look?
Eitan, this looks like to be a crash caused by the screen reader. Here, we're crashing when acquiring the MSG's monitor. The last stack frame probably looks funny because of identical-code-folding (CMDCaps' and MonitorAutoLock have a similar "Lock" methods). My guess is that for whatever reason, the graph has been destroyed on the main thread, but is still running its thread. Maybe a fallout from bug 1086545 ? In any case, a good way to debug this would be to enabled the lifetime logs and repro (see the macros at the top of MediaStreamGraph.cpp and GraphDriver.cpp). During the various part of the graph and stream shutdowns, info will be printed in the adb logcat, notably the invocation of the destructor of the MSG.
Flags: needinfo?(padenot) → needinfo?(eitan)
I need better steps to reproduce, tried all day with no luck. KTucker, do you still see this and are you able to reproduce reliably?
I crashed two times in a row today on the Flame 3.0 when trying to enter an email address in Firefox Accounts in Settings with screen reader on. Environmental Variables: Device: Flame 3.0(Full Flash)(KK)(319mb) BuildID: 20150528010203 Gaia: 05380df3158fa39e1dde1687c0bf11a71f8c6868 Gecko: baa9c64fea6f Gonk: 040bb1e9ac8a5b6dd756fdd696aa37a8868b5c67 Version: 41.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0 STR: 1. Full flash the Flame to the latest nightly build. 2. Progress through the FTE and turn on Screen Reader. 3. Select "Firefox Accounts" and tap on the "Create Account or Sign in" button. 4. Start entering an email address. (If no crash occurs, proceed to the password screen). 5. Start entering a password. Actual: A crash will occur when entering an email address or password when using screen reader to sign into Firefox Accounts.
QA Whiteboard: [QAnalyst-Triage+]
I still can't get a crash. No luck with the STR above either. If someone could manage to do it with this patch for logging purposes, that would be great.
Since I can't reproduce this, and since Paul actually understands the MSG lifecycles.. Paul, do you have any pointers on how this could be fixed or at least reliably reproduced?
I'm sorry, I have no clue about this one, if we can't repro.
Can we get a logging patch?
Attachment #8612497 [details] [diff] does that, but probably too verbose for m-c.
Comment 14 fulfilled the qawanted request.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
[Tracking Requested - why for this release]: moving to backlog until the repro rates increase.
Crash Signature: [@ mozilla::CDMCaps::Lock()] → [@ mozilla::CDMCaps::Lock()] [@ mozilla::CDMCaps::Lock]
Closing because no crash reported since 12 weeks.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.