Closed Bug 1142747 Opened 7 years ago Closed 3 years ago

[Accessibility] crash during FxA login with screen reader on - crash in mozilla::CDMCaps::Lock()


(Core :: Audio/Video: Playback, defect)

Gonk (Firefox OS)
Not set



tracking-b2g backlog
Tracking Status
b2g-v2.2r --- affected
b2g-master --- affected


(Reporter: ychung, Unassigned)



(Keywords: crash, Whiteboard: [3.0-Daily-Testing])

Crash Data


(3 files, 1 obsolete file)

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.

The crash occurs, and the device restarts.

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?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: steps-wanted
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
Flags: needinfo?(ktucker)
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.

The following similar crash occurred when I simply double tapped on the email field to invoke the keyboard:

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)
Filed bug 1143202 for comment 2's results.
Flags: needinfo?(pcheng) → needinfo?(ktucker)
Flags: needinfo?(ktucker)
Naoki, can you please take a look at this crash i got today while trying to reproduce this bug:

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.

A crash will occur while typing on the keyboard.
Flags: needinfo?(nhirata.bugzilla)
Attached file crashdump.txt (obsolete) —
associating the crash with the symbols
Flags: needinfo?(nhirata.bugzilla)
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.
Attached file crashdump.txt
corrected crashdump association.
Attachment #8589338 - Attachment is obsolete: true
Removing steps-wanted since I can get this crash to occur fairly consistently with the steps in Comment 5.
Keywords: steps-wanted
Component: Disability Access APIs → WebRTC: Audio/Video
QA: Is this still happening?
Paul, can you take a look?
Flags: needinfo?(padenot)
Keywords: qawanted
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?
Flags: needinfo?(ktucker)
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


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.

A crash will occur when entering an email address or password when using screen reader to sign into Firefox Accounts.
QA Whiteboard: [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
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?
Flags: needinfo?(padenot)
I'm sorry, I have no clue about this one, if we can't repro.
Flags: needinfo?(padenot)
Can we get a logging patch?
Attachment #8612497 [details] [diff] does that, but probably too verbose for m-c.
Flags: needinfo?(eitan)
Component: WebRTC: Audio/Video → Video/Audio
Comment 14 fulfilled the qawanted request.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
[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]
Component: Audio/Video → Audio/Video: Playback
Closing because no crash reported since 12 weeks.
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.