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

Status: RESOLVED FIXED

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

Description

[Liz Henry (:lizzard) (relman/hg->git project)]

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)

Comment 1

[Marcia Knous [:marcia]]

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.

Comment 2

[littleleshy]

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

Comment 3

[Andreas Pehrson [:pehrsons]]

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.

Comment 4

[Pascal Chevrel:pascalc]

Marking 63 back to affected based on comment #3. Susheel, that seems pretty bad, could you get this into SV queue? Thanks

Comment 5

[David Bolter [:davidb] (NeedInfo me for attention)]

James could this be a regression from that latest crash reporting work?

Comment 6

[James Willcox (:snorp) ([e-mail]) (he/him)]

(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.

Comment 7

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 8

[:sdaswani]

Removing NI as Petru is NI'ed.

Comment 9

[Petru-Mugurel Lingurar [:petru]]

Attachment: Bug 1504780 - Prevent crash if GeckoProfile path is not known;

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.

Comment 10

[Petru-Mugurel Lingurar [:petru]]

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

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2859c48a1a81
Prevent crash if GeckoProfile path is not known; r=geckoview-reviewers,snorp

Comment 12

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/2859c48a1a81

Comment 13

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for Beta approval when you get a chance.

Comment 14

[Petru-Mugurel Lingurar [:petru]]

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:

Comment 15

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/3bebbace6e4a