Closed Bug 1504780 Opened 1 year ago Closed 1 year ago

Crash in java.lang.NullPointerException: at org.mozilla.gecko.CrashReporterActivity.getProfileName(CrashReporterActivity.java)

Categories

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

Firefox 63
defect

Tracking

()

RESOLVED FIXED
Firefox 65
Tracking Status
firefox63 + wontfix
firefox64 + fixed
firefox65 + fixed

People

(Reporter: lizzard, Assigned: petru)

References

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

This crash shows up for 64 and 65 nightly, around 70 crashes in the last week including a few on 62.0.3 release. It's first showing up in volume for 64 nightly (but not beta).


This bug was filed from the Socorro interface and is
report bp-6574842f-badd-4924-816d-8e0ef0181104.
=============================================================

Java stack trace:

java.lang.NullPointerException
	at org.mozilla.gecko.CrashReporterActivity.getProfileName(CrashReporterActivity.java:343)
	at org.mozilla.gecko.CrashReporterActivity.onCreate(CrashReporterActivity.java:185)
	at android.app.Activity.performCreate(Activity.java:7149)
	at android.app.Activity.performCreate(Activity.java:7140)
	at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1288)
	at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3017)
	at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3172)
	at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:78)
	at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:108)
	at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:68)
	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1906)
	at android.os.Handler.dispatchMessage(Handler.java:106)
	at android.os.Looper.loop(Looper.java:193)
	at android.app.ActivityThread.main(ActivityThread.java:6863)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:537)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)
I saw this earlier during triage, but I didn't file it it since it appears it is only one device crashing, Oppa F1f running API 22. Not sure we would do much about this crash if is a single device that isn't that popular.
I get similar crashes after update to release 63.0.2.

java.lang.NullPointerException
 at org.mozilla.gecko.CrashReporterActivity.getProfileName(CrashReporterActivity.java:337)
 at org.mozilla.gecko.CrashReporterActivity.onCreate(CrashReporterActivity.java:179)
 at android.app.Activity.performCreate(Activity.java:7036)
 at android.app.Activity.performCreate(Activity.java:7027)
 at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1215)
 at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2731)
 at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2856)
 at android.app.ActivityThread.-wrap11(Unknown Source:0)
 at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1589)
 at android.os.Handler.dispatchMessage(Handler.java:106)
 at android.os.Looper.loop(Looper.java:164)
 at android.app.ActivityThread.main(ActivityThread.java:6501)
 at java.lang.reflect.Method.invoke(Native Method)
 at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
 at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)

https://crash-stats.mozilla.com/report/index/ed0be79c-0b6d-477c-b91f-4926c0181111
So this is what's been trying to brick my Samsung Galaxy S8 for the past week.

It first happened as I was trying to unlock my phone. It just turned black with no buttons available. Re-locking worked fine. After a while of frustration I notice that Samsung's "edge" app switcher is visible when trying to unlock. With this I could open another app (Camera in this case) and the regular home/app-drawer/back buttons appeared. But before I could continue the camera app disappeared and everything turned white. Luckily, with buttons still present.

Pressing Home, half a second later it turned all white again.

Pressing the app drawer, the white app is "Firefox Crash Reporter". Trying to kill it -- half a second later all white again.

Rinse and repeat.

What I found worked was to open Firefox within that half second. Most of the time this would make the madness stop.


This went on for a few days, me thinking that with all the crash reports we'd have a fix out soon. Well, last night I opened about:crashes and found page up and page down of *unsubmitted* crash reports of this bug. They'd mostly happen at night, as if they were triggered by inactivity and/or sufficient battery level.

Since this crash is in the crash reporter, I assume it's what kept the reports from getting submitted. Clicking on the reports would indeed submit them so I've done that to a bunch this morning. If you want more I reckon I have a couple thousand to go.

This bug seems particularly bad since if this is remotely widespread we won't be able to get reliable crash reports from Fennec, and won't be able to know about the frequency of this bug itself.

With this in mind I'm requesting tracking of this for release and up, and in all humbleness ask that this be investigated as a P1.
Marking 63 back to affected based on comment #3. Susheel, that seems pretty bad, could you get this into SV queue? Thanks
Flags: needinfo?(sdaswani)
James could this be a regression from that latest crash reporting work?
Flags: needinfo?(snorp)
(In reply to David Bolter [:davidb] (NeedInfo me for attention) from comment #5)
> James could this be a regression from that latest crash reporting work?

Maybe, but I don't see any obvious reason it would be related. I think Fennec just needs some null checking here.
Flags: needinfo?(snorp)
Petru might you or one of the others on the team have a look at this crash? From comment 3, it sounds like this may be more widespread than we're able to see in crash-stats results.
Flags: needinfo?(petru.lingurar)
Removing NI as Petru is NI'ed.
Flags: needinfo?(sdaswani)
Assignee: nobody → petru.lingurar
Status: NEW → ASSIGNED
Flags: needinfo?(petru.lingurar)
In this case the profile name will be null, situation already handled, in which
a telemetry ping about the crash will not be sent but the crash can still be
reported to crash-stats.
The value for "Path" is only set from GeckoProfile#createprofileDir()[1].

Looking at where this crash is occurring [2] it seems that:
- a Profile directory exists
- it doesn't contain a Profile
I think this might happen if persisting the Profile fails, in which case we just swallow the error [3].

It's already too late to do something for the current session, but maybe as a speculative fix to prevent this kind of situations it might be useful to verify and ensure we have persisted the profile, after first trying to writing it [4].

[1] https://dxr.mozilla.org/mozilla-central/rev/7488645b27ac9b273d6785db04204684673b3657/mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoProfile.java#946
[2] .https://dxr.mozilla.org/mozilla-central/rev/7488645b27ac9b273d6785db04204684673b3657/mobile/android/base/java/org/mozilla/gecko/CrashReporterActivity.java#343
[3] https://dxr.mozilla.org/mozilla-central/rev/7488645b27ac9b273d6785db04204684673b3657/mobile/android/geckoview/src/main/java/org/mozilla/gecko/util/INIParser.java#52
[4] https://dxr.mozilla.org/mozilla-central/rev/7488645b27ac9b273d6785db04204684673b3657/mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoProfile.java#960
Keywords: checkin-needed
Pushed by apavel@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2859c48a1a81
Prevent crash if GeckoProfile path is not known; r=geckoview-reviewers,snorp
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/2859c48a1a81
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 65
Please nominate this for Beta approval when you get a chance.
Flags: needinfo?(petru.lingurar)
Comment on attachment 9027135 [details]
Bug 1504780 - Prevent crash if GeckoProfile path is not known;

[Beta/Release Uplift Approval Request]

Feature/Bug causing the regression: None

User impact if declined: Application crash

Is this code covered by automated tests?: No

Has the fix been verified in Nightly?: No

Needs manual test from QE?: No

If yes, steps to reproduce: 

List of other uplifts needed: None

Risk to taking this patch: Low

Why is the change risky/not risky? (and alternatives if risky): Very small change that avoids a NullPointerException

String changes made/needed:
Flags: needinfo?(petru.lingurar)
Attachment #9027135 - Flags: approval-mozilla-beta?
Comment on attachment 9027135 [details]
Bug 1504780 - Prevent crash if GeckoProfile path is not known;

Crash fix, let's take this for the 64 RC build.
Attachment #9027135 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Depends on: 1497148
Duplicate of this bug: 1511727
You need to log in before you can comment on or make changes to this bug.