Closed Bug 1527243 Opened 3 years ago Closed 2 years ago

Crash in java.lang.NullPointerException: at$Builder.<init>(


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



(firefox-esr68 affected, firefox66 fixed, firefox67 affected)

Tracking Status
firefox-esr68 --- affected
firefox66 --- fixed
firefox67 --- affected


(Reporter: JanH, Unassigned)



(Keywords: crash)

Crash Data


(1 file)

+++ This bug was initially created as a clone of Bug #1516665 +++

Follow-up: For diagnostic purposes we're still crashing on Nightly, so we need to check the logs from a few recent crash reports and see if we can now come up with an explanation as to how they are happening.

@snorp: Could you please get logcats from some recent crash reports on Nightly that occurred after the extended debug logging in bug 1516665 landed?

Flags: needinfo?(snorp)

There are none with logcats so far, and only about 15-20 crashes on 67 with this signature.

Flags: needinfo?(snorp)

Marking this p3 as we've fixed the bulk of the crashes now.

Priority: P1 → P3

I got this issue just now. This happened after I force-killed firefox and tried to start it again. Although I don't know if the crash is from the killed instance or the new instance.
I wanted to force kill the browser because it wasn't responding anymore after I clicked the menu button. Also the small notification counter on the icon was blinking repeatedly in a fast succession.
Hope this helps :)

Assignee: nobody → brad.arant

Stacktrace of a recent crash from build 20190614203602

java.lang.NullPointerException: Attempt to invoke virtual method 'android.content.res.Resources android.content.Context.getResources()' on a null object reference
at android.os.Handler.dispatchMessage(
at android.os.Looper.loop(
at java.lang.reflect.Method.invoke(Native Method)

Look like context is null.

The GeckMediaControlAgent is a helper object that has a data member to contain the context (mContext). This static member is access through many static method calls which rely upon this context to be initialized through external processes.

I am submitting this patch which will ensure that the context is available to the notification helper when called through the static method and the mContext member variable is null.

The purpose of this is to see if this is indeed the issue and see if the nightly crash reports subside completely.

This crash is purposely induced on nightly because we want to see why the GeckoMediaControlAgent even gets in this state in the first place (there have been numerous reports of buggy behaviour regarding GMCA), fixing it still won't solve the underlying problem. There are multiple logs in place before it reaches this point, I suggest we find a way to look at those and find out what are the steps that lead us here.

The underlying issue deals with the fact that the OS may completely destroy the process accompanying the app when the app is in background. This is a known possibility with any app and it is up to the application to aproprietely manage the persistence of objects.
For this ticket in reviewing the dumps it is apparent that the mContext variable in the GeckMediaControlAgent (GMCA) has lost its reference either because the context has been reclaimed or the GMCA itself was reclaimed. In any event, the singleton style static reference to the instance will recreate the object but the mContext variable is not restored in time for the call to the Notification.Builder method.
Since this bug no longer is appearing in production due to a patch that allows the Notification.Builder to only be called if there is a valid context at this point in the code I believe we should just clean up that code and allow the check to be enabled for even the NIGHTLY and call this resolved.
This is acceptable as the use of the context should not be done without initialization from the other components. In essence, the mContext variable is an indicator that the object is ready.

This would mean that whatever we were trying to do with the notification is simply dropped under the table and ignored - granted, it's better than crashing, but it's still buggy behaviour.

Have not been able to recreate the scenario through memory pressure where the app completely closes the processes but I will occasionally try. Verification of this hypothesis is required to ensure adequate resolution.

Assignee: brad.arant → nobody

Marking 68 as affected. This is currently the top crash on 68.2a1.

This continues as the top crash for the latest nightly, 68.5a1.

I tried to reproduce the crash on Nightly 68.5a1 (2020-01-15) using a Samsung Galaxy Note 5 (Android 7.0) and Samsung Galaxy Note 9 (Android 9) by trying to trigger Push Notifications but was unable to. The following Push Notification were tested:

  • Download Notifications
  • Audio/Video Notification when watching videos or streams
  • Notification sent from various website after subscribing
  • "tab waiting" Notifications after opening links from other applications
We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly]( an issue can be reported at the [Fenix GitHub project]( If you want to discuss your report please use [Mozilla's chat]( server and join the [#fenix]( channel.
Closed: 2 years ago
Resolution: --- → INCOMPLETE
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.