Closed Bug 1292602 Opened 4 years ago Closed 4 years ago

Crash in java.lang.NullPointerException: at org.mozilla.gecko.GeckoAppShell.showAlertNotification(GeckoAppShell.java)

Categories

(Firefox for Android :: General, defect, P1, critical)

48 Branch
Unspecified
Android
defect

Tracking

()

RESOLVED FIXED
Firefox 51
Iteration:
1.3
Tracking Status
firefox48 --- wontfix
firefox49 + fixed
firefox50 + fixed
firefox51 --- fixed

People

(Reporter: marcia, Assigned: ahunt)

Details

(Keywords: crash, Whiteboard: [TPE-1][MobileAS])

Crash Data

Attachments

(1 file)

This bug was filed from the Socorro interface and is 
report bp-0e49b27a-d03e-4d8d-824a-089f82160805.
=============================================================

New crash showing up in 48 at #18: http://bit.ly/2aO6Tko. The crash was present in the betas leading up to release.

Comments don't contain much helpful information.
Priority: -- → P1
Whiteboard: [TPE-1]
I can look into this.
Assignee: nobody → ahunt
It looks like this can happen if gecko tries to show an alert before we've finished GeckoApp.onCreate() (we set the notification client at the end of onCreate). At that stage GeckoAppShell.notificationClient is not intialised yet, resulting in the NPE.

In which case we'd need to set the notification client before we start Gecko, to avoid this crash.

This fix is speculative, but it should fix the issue  if my understanding is correct.
Status: NEW → ASSIGNED
Whiteboard: [TPE-1] → [TPE-1][MobileAS]
Comment on attachment 8782971 [details]
Bug 1292602 - Set notification client before launching Gecko to avoid crash on notification

https://reviewboard.mozilla.org/r/72970/#review71354
Attachment #8782971 - Flags: review?(s.kaspari) → review+
This has now moved up to #3 top crash in 48. Can we get the fix checked in soon? Thanks.
Flags: needinfo?(ahunt)
[Tracking Requested - why for this release]: Looks like a top-crasher, we'll probably want this uplifted everywhere.
Flags: needinfo?(ahunt)
Pushed by ahunt@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6c9ce18c54e7
Set notification client before launching Gecko to avoid crash on notification r=sebastian
Track 49+/50+ as there are high volume of crashes in 48.
https://hg.mozilla.org/mozilla-central/rev/6c9ce18c54e7
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 51
We could potentially uplift this for Monday's fennec build.  Can you request uplift, and recommend some way we might ask QA to test the fix in nightly? We can try it in any case and see if it helps for beta 8.
Flags: needinfo?(ahunt)
Comment on attachment 8782971 [details]
Bug 1292602 - Set notification client before launching Gecko to avoid crash on notification

Approval Request Comment
[Feature/regressing bug #]: n/a
[User impact if declined]: Crash during startup under unknown circumstances (race condition, probably made more common by performance improvements in other code).
[Describe test coverage new/current, TreeHerder]: Manual testing, patch has landed on nightly without issues.
[Risks and why]: Low risk: existing setup call is now made before initialising the rest of Gecko during Fennec startup.
[String/UUID change made/needed]: none.
Flags: needinfo?(ahunt)
Attachment #8782971 - Flags: approval-mozilla-beta?
Attachment #8782971 - Flags: approval-mozilla-aurora?
Comment on attachment 8782971 [details]
Bug 1292602 - Set notification client before launching Gecko to avoid crash on notification

Fixes a crash, I didn't see any reports from Nightly that could be used for confirmation. Still makes sense to uplift to Aurora.
Attachment #8782971 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment on attachment 8782971 [details]
Bug 1292602 - Set notification client before launching Gecko to avoid crash on notification

Very last minute for beta, but let's put this in so we can test it for the mobile 49 beta 10 next Monday, since the crash volume is so high in 48.
Attachment #8782971 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Iteration: --- → 1.3
You need to log in before you can comment on or make changes to this bug.