[Email] Signing in to a Gmail as a second email account will freeze, lock up the device.

VERIFIED FIXED in Firefox 38

Status

()

defect
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: Marty, Assigned: kats)

Tracking

({regression})

unspecified
mozilla38
ARM
Gonk (Firefox OS)
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox36 wontfix, firefox37 wontfix, firefox38 fixed, b2g-v2.1 unaffected, b2g-v2.2 verified, b2g-master verified)

Details

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

Attachments

(3 attachments)

Reporter

Description

5 years ago
Posted file logcat-email.txt
Description:
If the user attempts to add a Gmail account to the email app after another email account has previously been added, the device will entirely lock up at the Gmail log-in screen.

Notes:
-The user must already have viewed the previous email accounts inbox for this to occur.  If both accounts are created sequentially, functionality will be retained appropriately.
-This may be similar to the issue described in Comment 3 of Bug 950045
   
Repro Steps:
1) Update a Flame device to BuildID: 20150115010229
2) Connect to a WiFi or Data network
3) Launch the Email app
4) Connect to an email account, and progress to the inbox
5) Tap the menu icon to open the Drawer and select the Gear icon
6) Select 'Add account'
7) Enter a Gmail address and select 'Next'
  
Actual:
The touch screen, and hardware buttons are unresponsive once the Gmail log-in page loads
  
Expected: 
User still has full device functionality after the Gmail log-in page loads
  
Environmental Variables:
Device: Flame 3.0 Master (Full Flash) (319MB)
BuildID: 20150115010229
Gaia: bcc76f93f5659ac1eb8a769167109fd2d7ca4fbd
Gecko: c1f6345f2803
Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76
Version: 38.0a1 (3.0 Master)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0
  
Notes: This issue occurs on both 512MB and 319MB memory
  
Repro frequency: 6/6
See attached: video clip (URL), logcat

------------------------------------

This issue DOES occur on Flame 2.2
The touch screen, and hardware buttons are unresponsive once the Gmail log-in page loads

Environmental Variables:
Device: Flame 2.2
BuildID: 20150115002505
Gaia: 7c5b27cad370db377b18a742d3f3fdb0070e899f
Gecko: ce27f2692382
Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76
Version: 37.0a2 (2.2)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

------------------------------------

This issue does NOT occur on Flame 2.1
User still has full device functionality after the Gmail log-in page loads

Environmental Variables:
Device: Flame 2.1
BuildID: 20150115001207
Gaia: 8d4846d7bec777046dc5e3d2b8005adb1370f1f7
Gecko: 8eb9bc3a945a
Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76
Version: 34.0 (2.1)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Reporter

Updated

5 years ago
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
This is going to be some type of system/platform issue and is unlikely to be email specific.  The only interesting things in the log are:

- APZC indicating that it's falling back to a default gf::Matrix4x4() for mTransformToApzc instead of having a target (after all the CSS warnings, so probably shortly after page display has largely begun).  This type of thing could perhaps explain some type of non-responsiveness to gestures on the screen, but unless it's sending the main thread into an infinite loop, that wouldn't explain why the home button wouldn't work.  That's from this log entry:
01-15 10:46:52.620: I/Gecko(216): 0xae9605f0 replacing unconfirmed target 0xa9e88800 with real target 0x0

- The profiler seems to have run in the main process for some reason.  If you didn't explicitly turn on the profiler, then this could be indicating that the main thread did get stuck doing something and the hang/jank detector activated itself.

I'd look for similar bugs across the system and then maybe do a regression check / notify the graphics team.  If the profiler dumped a backtrace somewhere, that is likely to be useful; attaching gdb could also be handy.
Hm, so there may be some reason to suspect the landing of bug 1117712 as causing this problem.  I commented on bug 1117712 comment 54.  I would perhaps suspect the landing described in https://bugzilla.mozilla.org/show_bug.cgi?id=1117712#c48 as a quick test...
[Blocking Requested - why for this release]:
Functional regression of a core feature,

window already requested, see Comment 2.
blocking-b2g: --- → 2.2?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
QA Contact: bzumwalt
I followed the STR in comment 0 using buildid 20150115010229 on a Flame and was unable to repro. Waiting for a regression window before spending any more time on this.
Gecko Regression Window:

Last working Gecko mozilla-inbound build:
Device:  2.2
BuildID: 20150108061600
Gaia: d4dac29613076bdba3cb8adc217deadb08a2ac20
Gecko: 3b29b9cdedfc
Version: 37.0a1 (2.2)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

First broken Gecko mozilla-inbound build:
Device: Flame 2.2
BuildID: 20150108064122
Gaia: 82b534791a72ad59c78363df80459e18d35b48f8
Gecko: 5d506eb6fd4c
Version: 37.0a1 (2.2)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Working Gaia with Broken Gecko issue DOES occur:
Gaia: d4dac29613076bdba3cb8adc217deadb08a2ac20
Gecko: 5d506eb6fd4c

Working Gecko with Broken Gaia issue does NOT occcur:
Gaia: 82b534791a72ad59c78363df80459e18d35b48f8
Gecko: 3b29b9cdedfc

Gecko Mozilla-Inbound Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3b29b9cdedfc&tochange=5d506eb6fd4c

Most likely due to bug 1109873
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Issue also occurs in todays Flame 3.0 Master

The touch screen, and hardware buttons are unresponsive once the Gmail log-in page loads after adding it as second account.

Device: Flame 3.0 Master
BuildID: 20150116060902
Gaia: 5ae81fcc0d8568a50d0bf8491004bc9485b3a9ae
Gecko: 5438e3f74848
Version: 38.0a1 (3.0 Master)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0
Ok, I can reproduce if I try to add the *same* gmail account twice.
Assignee: nobody → bugmail.mozilla
Component: Gaia::E-Mail → Panning and Zooming
Product: Firefox OS → Core
The problem appears to be that in some cases BuildOverscrollHandoffChain can call GetTargetAPZC. BuildOverscrollHandoffChain acquires the tree lock, and GetTargetAPZC calls GetTargetNode which also attempts to acquire the tree lock and deadlocks on itself. Should be easy to fix.
Attachment #8550502 - Flags: review?(botond) → review+
Comment on attachment 8550503 [details] [diff] [review]
Part 2 - Don't try to reacquire a lock we already have

Review of attachment 8550503 [details] [diff] [review]:
-----------------------------------------------------------------

Good catch!
Attachment #8550503 - Flags: review?(botond) → review+
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
https://hg.mozilla.org/mozilla-central/rev/88f7f6c66882
https://hg.mozilla.org/mozilla-central/rev/0844cea3c2d5
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
Comment on attachment 8550502 [details] [diff] [review]
Part 1 - Move lock up a level

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 1109873
User impact if declined: in some conditions with nested scrollable subframes the root process might deadlock and require the user to reboot
Testing completed: locally
Risk to taking this patch (and alternatives if risky): low-risk patch
String or UUID changes made by this patch: none
Attachment #8550502 - Flags: approval-mozilla-b2g37?
Attachment #8550503 - Flags: approval-mozilla-b2g37?

Updated

5 years ago
blocking-b2g: 2.2? → ---
Attachment #8550502 - Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37+
Attachment #8550503 - Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37+
This issue is verified fixed on Flame 2.2 and Master.

Result: The device does NOT freeze, and the user can successfully add a Gmail account as a second account.

Device: Flame 2.2 (319mb, full flash)
Build ID: 20150126002536
Gaia: 0518f4581a0925c0b703d730ef289ab15cbd1216
Gecko: c6aa604a7967
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 37.0a2 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Device: Flame Master (319mb, full flash)
Build ID: 20150126010231
Gaia: 0f662dffef27599443cfcd790c2b39190a2b35c8
Gecko: fa91879c8428
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
You need to log in before you can comment on or make changes to this bug.