Closed Bug 756734 Opened 12 years ago Closed 12 years ago

java.lang.NullPointerException: at org.mozilla.gecko.GeckoApp$16.run(GeckoApp.java)

Categories

(Firefox for Android Graveyard :: General, defect)

14 Branch
ARM
Android
defect
Not set
critical

Tracking

(firefox14 affected)

RESOLVED FIXED
Firefox 15
Tracking Status
firefox14 --- affected

People

(Reporter: scoobidiver, Assigned: bnicholson)

Details

(Keywords: crash, Whiteboard: [native-crash][startupcrash][14.0b2])

Crash Data

Attachments

(1 file)

There are 4 crashes from the same user in 14.0b2: bp-6ede2ce3-3daf-45e8-bc22-8bf0c2120519.

java.lang.NullPointerException
	at org.mozilla.gecko.GeckoApp$16.run(GeckoApp.java:993)
	at android.os.Handler.handleCallback(Handler.java:605)
	at android.os.Handler.dispatchMessage(Handler.java:92)
	at android.os.Looper.loop(Looper.java:137)
	at android.app.ActivityThread.main(ActivityThread.java:4581)
	at java.lang.reflect.Method.invokeNative(Native Method)
	at java.lang.reflect.Method.invoke(Method.java:511)
	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551)
	at dalvik.system.NativeStart.main(Native Method)

More reports at:
https://crash-stats.mozilla.com/report/list?signature=java.lang.NullPointerException%3A+at+org.mozilla.gecko.GeckoApp%2416.run%28GeckoApp.java%29
Looks like this is from this line:
http://hg.mozilla.org/releases/mozilla-aurora/file/ecb8c62dac5a/mobile/android/base/GeckoApp.java#l993

sMenu is guaranteed to not be null, so it seems like the only explanation is that sMenu.findItem(R.id.char_encoding) is null, but I'm also not sure how that's possible.
Maybe the menu was closed by the time the Runnable was executed. We should move the null check inside the Runnable.

We make a similar mistake in other places, such as:

if (Tabs.getInstance().isSelectedTab(tab)) {
    mMainHandler.post(new Runnable() {
        public void run() {
            mLayerController.getView().getTouchEventHandler().setWaitForTouchListeners(true);
        }
    });
}

and

if (mAboutHomeContent != null) {
    mMainHandler.post(new Runnable() {
        public void run() {
            mAboutHomeContent.setLastTabsVisibility(false);
        }
    });
}
Attached patch patchSplinter Review
Move checks inside Runnables.
Assignee: nobody → bnicholson
Attachment #626252 - Flags: review?(mark.finkle)
Comment on attachment 626252 [details] [diff] [review]
patch

                public void run() {
>+                        if (sMenu != null) {
>                             sMenu.findItem(R.id.char_encoding).setVisible(visible);
>                         }

{} not needed for a one-liner

>+                    public void run() {
>+                        if (Tabs.getInstance().isSelectedTab(tab)) {
>                             mLayerController.getView().getTouchEventHandler().setWaitForTouchListeners(true);
>                         }

same

>+                    public void run() {
>+                        if (mAboutHomeContent != null) {
>                             mAboutHomeContent.setLastTabsVisibility(false);
>                         }

same

Having the if checks outside the runnable, as well as inside, save us from creating a runnable sometimes. But this is probably not as useful as making sure the checks are done _inside_ the runnable.
Attachment #626252 - Flags: review?(mark.finkle) → review+
https://hg.mozilla.org/mozilla-central/rev/2ef3e8cef102
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 15
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: