Closed Bug 1078304 Opened 10 years ago Closed 10 years ago

crash in mozilla::widget::android::GLController::CreateEGLSurfaceForCompositorWrapper()

Categories

(Firefox for Android Graveyard :: Toolbar, defect)

35 Branch
All
Android
defect
Not set
critical

Tracking

(firefox34 unaffected, firefox35+ verified, firefox36+ verified, firefox37+ verified, fennec35+)

VERIFIED FIXED
Firefox 37
Tracking Status
firefox34 --- unaffected
firefox35 + verified
firefox36 + verified
firefox37 + verified
fennec 35+ ---

People

(Reporter: aaronmt, Assigned: jchen)

References

Details

(Keywords: crash, reproducible, topcrash-android-armv7)

Crash Data

Attachments

(1 file)

This bug was filed from the Socorro interface and is report bp-a06defdd-14ea-4b13-a855-9176e2141005. =============================================================
I just reproduced this crash - Sony Xperia Z2 with Fennec 35.0a1 on first run. Report: bp-0c53433e-24bb-4dd8-b600-585822141008
This is now a top-crash and comments suggest this is a startup or firstrun screen crash
[Tracking Requested - why for this release]:
tracking-fennec: --- → ?
Do we have STR for this? Also a regression range (based on crash-stats)?
First build on crash stats is 2014-10-02-03:02:02 Possible regression range http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=14665b1de5ee&tochange=2399d1ae89e9
Possibly a regression from bug 888482, it looks related.
Flags: needinfo?(nchen)
Confirmed I hit this immediately on my Nexus 7 (2012) on new profile (with the first-run activity showing) https://crash-stats.mozilla.com/report/index/5f70539b-b3e2-4556-9b53-bdc392141014
Keywords: reproducible
There are a number of crashes circulating related to the first-run, I wonder if this is related as well.
I/Gecko ( 6790): Attempting load of libEGL.so E/GeckoLayerView( 6790): Error registering compositor! E/GeckoLayerView( 6790): java.lang.NullPointerException E/GeckoLayerView( 6790): at org.mozilla.gecko.gfx.LayerView.registerCxxCompositor(LayerView.java:525) E/GeckoLayerView( 6790): at dalvik.system.NativeStart.run(Native Method) E/GeckoLayerView( 6790): at dalvik.system.NativeStart.run(Native Method) I/ActivityManager( 508): Process org.mozilla.fennec (pid 6790) has died. I think this is essentially bug 1081768
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
This crash is 100% reproducible on Sony Xperia Z2 10.1 (4.4.2) when starting Fennec with a clean profile https://crash-stats.mozilla.com/report/index/bp-51a2c161-2380-4d16-bae7-b8f642141014 Nightly 36 and Aurora 35 are affected.
Catalin, if this is 100% reproducible for you, can you check to see if it was bug 888482 that introduced this?
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #13) > Catalin, if this is 100% reproducible for you, can you check to see if it > was bug 888482 that introduced this? Could be. Nightly stared to crash after landing the patches from this bug This is the regression range http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=14665b1de5ee&tochange=5d6ec4dddf14
(In reply to Catalin Suciu from comment #14) > (In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #13) > > Catalin, if this is 100% reproducible for you, can you check to see if it > > was bug 888482 that introduced this? > > Could be. Nightly stared to crash after landing the patches from this bug > This is the regression range > http://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=14665b1de5ee&tochange=5d6ec4dddf14 Please check on inbound.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #16) > The relevant before/after inbound builds are: > > http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla- > inbound-android/1412115144/ Doesn't crash > http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla- > inbound-android/1412115924/ Crashes at startup with this signature: libxul.so@0xacb876 | libxul.so@0xac3b89 | libxul.so@0xac3aff | libxul.so@0x1bbb46e | libxul.so@0x665117 | libmozglue.so@0x1e667 https://crash-stats.mozilla.com/report/index/ed630f4c-c217-4a9f-a894-195612141015 The next few inbound builds that I tested are all crashing with the above signature
Thanks. I added a comment to bug 1081768 which this was duped to.
Flags: needinfo?(nchen)
tracking-fennec: ? → 35+
This looks like a subtly different case than Bug 1081768, even if it has the same cause, so I'm unduping.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
[Tracking Requested - why for this release]: top crash for Android and the current the main cause of the increase of the crash rate from 34b to 35b
tracking-fennec: 35+ → ?
Topcrash, tracking.
Assignee: nobody → nchen
tracking-fennec: ? → 35+
Jim - we only have two more mobile betas left in the cycle to get something landed and collecting feedback on this topcrasher - do you have any leads or potential patches coming up? We're going to build 35.0b8 this afternoon (in a few hours) and then 35.0b10 on Monday Jan 5th.
Flags: needinfo?(nchen)
I have a patch that's stuck on one test failure right now. Hopefully I'll get it sorted out over the next day or so. https://treeherder.mozilla.org/#/jobs?repo=try&revision=71b4dcb0e5b6
Flags: needinfo?(nchen)
Attached patch Call setLayerView early (v1) (deleted) — Splinter Review
This patch should fix the crash. And it's the lowest risk one I came up with. Instead of calling GeckoAppShell.setLayerView during GeckoApp.onWindowFocusChanged, we call it during layout inflation through the GeckoView constructor, which is what non-Fennec GeckoView is already doing. I thought about moving the initializeView call too, but I think that's actually more risk. I looked at the code a bit and experimented with actual builds, and there seems to be no problem leaving the initializeView call as-is. We definitely need a follow-up to address this more fully though. I removed the forceRedraw line in LayerView.setInputConnectionHandler because it was causing a startup crash and it seemed to be some legacy code that's no longer relevant -- when that line was added, LayerView.setInputConnectionHandler was being called at a different stage of starting up.
Attachment #8543061 - Flags: review?(snorp)
Attachment #8543061 - Flags: review?(snorp) → review+
Pushed to m-c directly because try looks good [1], tomorrow is New Year's, and we only have a few Nightlies to bake this on before we have to uplift for the next Beta. [1] https://treeherder.mozilla.org/#/jobs?repo=try&revision=811f34d6aeca https://hg.mozilla.org/mozilla-central/rev/f6538af6ddac
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Comment on attachment 8543061 [details] [diff] [review] Call setLayerView early (v1) Approval Request Comment [Feature/regressing bug #]: N/A [User impact if declined]: Crash on first-run on some devices (topcrash). [Describe test coverage new/current, TBPL]: Local and m-c. [Risks and why]: Not zero but should be small. The patch touches the startup code which is known to be fragile. However, it changes as few things as possible so the risk is about as small as we can get. [String/UUID change made/needed]: None
Attachment #8543061 - Flags: approval-mozilla-beta?
Attachment #8543061 - Flags: approval-mozilla-aurora?
Attachment #8543061 - Flags: feedback+
Comment on attachment 8543061 [details] [diff] [review] Call setLayerView early (v1) Big finger :/
Attachment #8543061 - Flags: feedback+
Attachment #8543061 - Flags: approval-mozilla-aurora?
Attachment #8543061 - Flags: approval-mozilla-aurora+
Comment on attachment 8543061 [details] [diff] [review] Call setLayerView early (v1) We'll take this into the final mobile beta as it is a topcrash and we could benefit from a stability fix for this cycle.
Attachment #8543061 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
This crash is no longer reproducible. Verifying as fixed.
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: