crash in java.lang.NullPointerException: at org.mozilla.gecko.health.BrowserHealthReporter$<n>.run(BrowserHealthReporter.java)

RESOLVED FIXED in Firefox 23

Status

()

defect
--
critical
RESOLVED FIXED
6 years ago
3 years ago

People

(Reporter: scoobidiver, Assigned: nalexander)

Tracking

({crash, regression})

23 Branch
Firefox 25
ARM
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox22 unaffected, firefox23 fixed, firefox24 fixed, firefox25 fixed)

Details

(crash signature)

Attachments

(1 attachment)

There are 2 reports including bp-4fab2750-a618-4a03-bac2-1ce692130628.

java.lang.NullPointerException
	at org.mozilla.gecko.health.BrowserHealthReporter$1.run(BrowserHealthReporter.java:128)
	at android.os.Handler.handleCallback(Handler.java:725)
	at android.os.Handler.dispatchMessage(Handler.java:92)
	at android.os.Looper.loop(Looper.java:137)
	at org.mozilla.gecko.util.GeckoBackgroundThread.run(GeckoBackgroundThread.java:32)

More reports at:
https://crash-stats.mozilla.com/query/?product=FennecAndroid&query_search=signature&query_type=contains&query=org.mozilla.gecko.health.BrowserHealthReporter&reason=&do_query=1
tracking-fennec: --- → ?
Huzzah for null handling logic fail.
Assignee: nobody → nalexander
I have yet to test this on device; will update the ticket when I have.
Attachment #769019 - Flags: review?(rnewman)
Attachment #769019 - Flags: review?(rnewman) → review+
https://hg.mozilla.org/services/services-central/rev/4dd3f364981f
Status: NEW → ASSIGNED
Target Milestone: --- → Firefox 25
Whiteboard: [fixed in services]
https://hg.mozilla.org/mozilla-central/rev/4dd3f364981f
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Whiteboard: [fixed in services]
Comment on attachment 769019 [details] [diff] [review]
Make sure generated report is not null in BrowserHealthReporter. r=rnewman

[Approval Request Comment]
Bug caused by (feature/regressing bug #): This is fallout from Bug 888665, which caused the health report backend to yield a null document in the presence of bad addons initialization. 

User impact if declined: crashes in the rare instances when the health report backend fails.  We don't expect this to be frequent, but it is possible and in the API.

Testing completed (on m-c, etc.): essentially none.  about:healthreport still works locally, and will be verified as part of any uplift.  This just landed on m-c and the error condition should happen only in very rare situations post Bug 888665, so manual testing is not really feasible.

Risk to taking this patch (and alternatives if risky): mild.  This does rework error handling, which could introduce additional errors.  The alternative is to accept hard crashes in the presence of believed-to-be-rare but unpredictable failures.

String or IDL/UUID changes made by this patch: none.
Attachment #769019 - Flags: approval-mozilla-beta?
Attachment #769019 - Flags: approval-mozilla-aurora?
Comment on attachment 769019 [details] [diff] [review]
Make sure generated report is not null in BrowserHealthReporter. r=rnewman

Approving on aurora only for now so this gets landed and baked for a few days given the mild risk as the code has touched general error handling.

if the fallout's are obvious, we'll backout.
Attachment #769019 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Attachment #769019 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
tracking-fennec: ? → ---
You need to log in before you can comment on or make changes to this bug.