Closed Bug 1483993 Opened 2 years ago Closed 2 years ago
crash in java
.lang .Null Pointer Exception: Attempt to invoke virtual method 'boolean java .lang .String .equals(java .lang .Object)' on a null object reference at org .mozilla .gecko .Crash Reporter Activity .get Profile Name(Crash Reporter Activity .java)
While (successfully) attempting to reproduce bug 1483893 on my phone (Moto G4 Play, Android 6.0.1), I've noticed that the crash reporter itself is crashing as well. This happens even after clearing app data and running with a completely fresh profile: > 08-16 21:12:33.433 11745-11745/? E/GeckoCrashHandler: >>> REPORTING UNCAUGHT EXCEPTION FROM THREAD 1 ("main") > java.lang.NullPointerException: Attempt to invoke virtual method 'boolean java.lang.String.equals(java.lang.Object)' on a null object reference > at org.mozilla.gecko.CrashReporterActivity.getProfileName(CrashReporterActivity.java:336) > at org.mozilla.gecko.CrashReporterActivity.onCreate(CrashReporterActivity.java:178) > at android.app.Activity.performCreate(Activity.java:6259) > at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1130) > at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2382) > at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2493) > at android.app.ActivityThread.-wrap11(ActivityThread.java) > at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1357) > at android.os.Handler.dispatchMessage(Handler.java:102) > at android.os.Looper.loop(Looper.java:148) > at android.app.ActivityThread.main(ActivityThread.java:5459) > at java.lang.reflect.Method.invoke(Native Method) > at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:728) > at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:618)
This might also again be something Android version specific: I'm fairly certain that bug 1483893 should affect older Android versions as well, but Crash Stats is only showing reports from API26 and above.
Jan do you have any idea how often this bug happens? Is it frequent?
Flags: needinfo?(sdaswani) → needinfo?(jh+bugzilla)
(In reply to Jan Henning [:JanH] from comment #1) > This might also again be something Android version specific: I'm fairly > certain that bug 1483893 should affect older Android versions as well, but > Crash Stats is only showing reports from API26 and above. I'm seeing crash reports from older version as well, just for that particular case the crash signature is reported slightly different, which blows that theory out of the water. (In reply to :sdaswani only needinfo from comment #3) > Jan do you have any idea how often this bug happens? Is it frequent? When forcing a crash via about:crashparent (i.e. crashing from Gecko), the crash reporter worked normally, whereas with a crash in Java code like bug 1483893 the crash reporter itself always crashed.
Susheel, can you triage this bug please? This is tracking-firefox63+ so patches will require an uplift on the beta branch. Thanks!
Vlad I think this needs to get fixed sooner rather than later.
Flags: needinfo?(sdaswani) → needinfo?(vlad.baicu)
Seems like some work has been done on this area by snorp on bug 1483329 which might have fixed this issue, however it also introduced bug 1490664 which prevents me from testing until that one gets sorted out.
Depends on: 1490664
Tested with Oneplus 6 running Android O and have been unable to reproduce the issue since snorp's patches. Jan, are you still encountering this issue ?
I need to create a Try build that causes a crash from Java in order to test this.
In some scenarios profileDir is null which can cause a crash. Added a Nullable annotation to warn of this possibility and a null check to prevent the exception from happening.
I tried getting to the root of the cause, but since I have been unable to reproduce it and gather more info, the best I can do for now is this speculative fix if it continues to reproduce.
Comment on attachment 9009146 [details] Bug 1483993 - Check if profileDir is null before accessing it. r=sdaswani Jim Chen [:jchen] [:darchons] has approved the revision.
Attachment #9009146 - Flags: review+
Ryan is this another we need to get in 63?
Once it lands on m-c, absolutely.
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/c91289fdc4f1 Check if profileDir is null before accessing it. r=jchen
Please request Beta approval on this when you get a chance.
Comment on attachment 9009146 [details] Bug 1483993 - Check if profileDir is null before accessing it. r=sdaswani Approval Request Comment [Feature/Bug causing the regression]: The profile directory is null under some circumstances [User impact if declined]: Low - Medium . In case users experience crashes, they might also have the crash reporter crash. [Is this code covered by automated tests?]: No [Has the fix been verified in Nightly?]: No [Needs manual test from QE? If yes, steps to reproduce]: Would be helpful but I have been unable to reproduce on m-c. [List of other uplifts needed for the feature/fix]: - [Is the change risky?]: No [Why is the change risky/not risky?]: The change implies a simple null check of the profile directory. [String changes made/needed]: -
Attachment #9009146 - Flags: approval-mozilla-beta?
Comment on attachment 9009146 [details] Bug 1483993 - Check if profileDir is null before accessing it. r=sdaswani Crash fix, uplift approved for 63 beta, thanks.
Attachment #9009146 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
I wasn't able to reproduce the issue with OnePlus 5T(Android 8.1.0), LG G4 (Android 6.0) and Motorola Nexus 6 (Android 7.1.1) in the latest version of Firefox Nightly 64.0a1 (2018-09-24) and Firefox 63.0b9. Based on that I will set this issue as verified.
I'm not absolutely sure, because the crash reporter in my local build is currently only partially enabled (MOZ_CRASHREPORTER is set, but some bits depend on MOZILLA_OFFICIAL, which I haven't set), but I've hit some other Java crash during testing and this time the crash reporter appeared normally. So I guess that everything should indeed be working now.
You need to log in before you can comment on or make changes to this bug.