Closed Bug 888250 Opened 7 years ago Closed 7 years ago
crash in java
.lang .Null Pointer Exception: at org .mozilla .gecko .health .Browser Health Reporter$<n>.run(Browser Health Reporter .java)
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
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+
Status: NEW → ASSIGNED
Target Milestone: --- → Firefox 25
Status: ASSIGNED → RESOLVED
Closed: 7 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.
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+
You need to log in before you can comment on or make changes to this bug.