760267 - java.lang.NullPointerException: at org.mozilla.gecko.GeckoApp.onPrepareOptionsMenu(GeckoApp.java) at org.mozilla.gecko.GeckoApp.invalidateOptionsMenu(GeckoApp.java)

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Scoobidiver (away)]

There's one crash in 14.0a2/20120530: bp-3a2e338c-e9cd-43bb-afa2-ce8c22120530.

java.lang.NullPointerException
	at org.mozilla.gecko.GeckoApp.onPrepareOptionsMenu(GeckoApp.java:433)
	at org.mozilla.gecko.GeckoApp.invalidateOptionsMenu(GeckoApp.java:383)
	at org.mozilla.gecko.Tabs$2.run(Tabs.java:141)
	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:4424)
	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.onPrepareOptionsMenu%28GeckoApp.java%29

Comment 1

[Scoobidiver (away)]

It's #6 top crasher in 14.0b6. The Aurora regression range is:
http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=74f5e0d677f2&tochange=89176b6d643c
It's likely a regression from bug 753200.

Comment 2

[Mark Finkle (:mfinkle) (use needinfo?)]

We need to look at the fix to determine if we want to just back out the original patch.

Comment 3

[Sriram Ramasubramanian [:sriram]]

What all devices are actually having this crash?

Comment 4

[Sriram Ramasubramanian [:sriram]]

This particular crash happens, if the builds aren't clobbered.
In the current code in beta:
1. invalidateOptionsMenu() does a null check on menu before calling onPrepareOptionsMenu()
2. onPrepareOptionsMenu(), hence, crashes on finding the "settings" menu-item. And, we have settings menu-item in the XML (there is only one XML) for a long time now.

I've seen this particular crash, every time a new resource is added and the build is not clobbered. And regarding the crashes in versions 15 and 16, I speculate them to be raised by developers experiencing this when not clobbering.

It's better to clobber "resources/" folder for android for every build. I do this all the time, and haven't seen a build time longer than 10secs to copy all the resources again.

Comment 5

[Matt Brubeck (:mbrubeck)]

I'm not sure this only happens in unclobbered builds; we have over a hundred crash reports from the official 14.0 beta builds, which I believe are clobber builds.

Comment 6

[Scoobidiver (away)]

85% of crashes happen within one minute.

Comment 7

[Aaron Train [:aaronmt]]

(In reply to Matt Brubeck (:mbrubeck) from comment #5)
> I'm not sure this only happens in unclobbered builds; we have over a hundred
> crash reports from the official 14.0 beta builds, which I believe are
> clobber builds.

CC'ing Aki to clarify

Comment 8

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Device listings based on report : https://crash-analysis.mozilla.com/rkaiser/2012-06-11/2012-06-11.fennecandroid.aurora.devices.weekly.html
 
java.lang.NullPointerException: at org.mozilla.gecko.GeckoApp.onPrepareOptionsMenu(GeckoApp.java) 	21
HP Touchpad 	12
Samsung GT-I9000 	5
Samsung GT-N7000 	2
Unknown AN8G2 	1
MID 2GO

Comment 9

[Scoobidiver (away)]

(In reply to Naoki Hirata :nhirata from comment #8)
> Device listings based on report :
> https://crash-analysis.mozilla.com/rkaiser/2012-06-11/2012-06-11.
> fennecandroid.aurora.devices.weekly.html
Crashes on Aurora up to 14.0a2/20120604 are related to this bug.
Crashes on Aurora from 15.0a2/20120609 are related to bug 760357, not this one.

Comment 10

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

OS version doesn't seem to matter after all (sort by OS)

https://crash-stats.mozilla.com/report/list?query_search=signature&query_type=contains&reason_type=contains&range_value=4&range_unit=weeks&hang_type=any&process_type=any&signature=java.lang.NullPointerException%3A%20at%20org.mozilla.gecko.GeckoApp.onPrepareOptionsMenu%28GeckoApp.java%29&admin=1

It should occur on the release beta according to what I see.

There are some of the crashes that are occurring that are not startup crashes.  They have a different stack:

java.lang.NullPointerException
	at org.mozilla.gecko.GeckoApp.onPrepareOptionsMenu(GeckoApp.java:444)
	at android.app.Activity.onPreparePanel(Activity.java:2174)
	at org.mozilla.gecko.GeckoApp.onPreparePanel(GeckoApp.java:566)
	at com.android.internal.policy.impl.PhoneWindow.preparePanel(PhoneWindow.java:341)
	at com.android.internal.policy.impl.PhoneWindow.onKeyDownPanel(PhoneWindow.java:665)
	at com.android.internal.policy.impl.PhoneWindow.onKeyDown(PhoneWindow.java:1367)
	at com.android.internal.policy.impl.PhoneWindow$DecorView.dispatchKeyEvent(PhoneWindow.java:1829)
	at android.view.ViewRoot.deliverKeyEventToViewHierarchy(ViewRoot.java:2564)
	at android.view.ViewRoot.handleFinishedEvent(ViewRoot.java:2539)
	at android.view.ViewRoot.handleMessage(ViewRoot.java:1871)
	at android.os.Handler.dispatchMessage(Handler.java:99)
	at android.os.Looper.loop(Looper.java:130)
	at android.app.ActivityThread.main(ActivityThread.java:3683)
	at java.lang.reflect.Method.invokeNative(Native Method)
	at java.lang.reflect.Method.invoke(Method.java:507)
	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597)
	at dalvik.system.NativeStart.main(Native Method)

This is on GT-I9100, Nook Tablet, MID Ramos W12, NookColor, SEBM912HC Uniseb Tablet Yifang M912

Comment 11

[Scoobidiver (away)]

(In reply to Naoki Hirata :nhirata from comment #10)
> There are some of the crashes that are occurring that are not startup
> crashes.  They have a different stack:
It's bug 760357 as stated in comment 9.

Comment 12

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Devices affected over all:

Samsung Nexus S 	15
Samsung GT-I9100 	12
Samsung Galaxy Nexus 	9
Samsung GT-I9300 	8
Samsung GT-N7000 	8
Unknown MID 	6
Sony Ericsson MT11i 	5
Samsung GT-I9000 	5
Zenithink ZT ICS 	3
Samsung Nexus S 4G 	3
Motorola MB525 	3
Amazon Galaxy Nexus 	2
HTC Sensation Z710e 	2
Samsung SPH-D700 	2
Sony Ericsson ST18i 	2
Motorola A953 	2
Sony Ericsson LT18i 	2
Motorola MB526 	2
Unknown A10-MID 	1
Sony Ericsson WT19i 	1
Unknown Desire S 	1
Unknown N12 	1
LGE LG-P990 	1
Unknown novo7_Advanced2 	1
Unknown XELIO 	1
Unknown PLOYER-MOMO 	1
Sony Ericsson LT15i 	1
Samsung GT-I9100G 	1
HTC Sensation XE with Beats Audio Z715e 	1
Motorola MB855 	1
Samsung GT-P3113 	1
Allwinner A10 	1
Motorola DROID2 	1
Motorola XT910 	1
Samsung SPH-D710 	1
Sony Ericsson SK17i

Comment 13

[Aaron Train [:aaronmt]]

Tested last evening with a variety of devices all using 14.0b6 and had no luck reproducing this.

Comment 14

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Looking at the code, does this mean that Settings could not be found?  The only thing I could think of was changing the languages, and that did not reproduce on the Nexus S.  I tried testing this morning as well as last evening and I could not reproduce this.

Comment 15

[Aaron Train [:aaronmt]]

Are we sure these are market builds?

Comment 16

[Sriram Ramasubramanian [:sriram]]

*spark in the morning*
What if GeckoApp restarts for some reason, changing the context? The application might be still running. In this case, "static" variable "sMenu" is not null, hence skips the check in invalidateOptionsMenu() and goes to onPrepareOptionsMenu(), tries to find the item in the menu, and fails.
 - This is for Nexus phones.
 - Solution: Unnecessary "static" needs to be removed.

Comment 17

[Brad Lassey [:blassey] (use needinfo?)]

Sriram, let's get the static variable -> member variable change landed on trunk ASAP and respin the nightly so we can get as much testing as possible.

Comment 18

[Sriram Ramasubramanian [:sriram]]

Attachment: Patch (1/2): Removing the static variable

This patch removes the static variable.

Comment 19

[Sriram Ramasubramanian [:sriram]]

Attachment: Patch (2/2): OCD

This patch renames the member variable to be mXxx.
Also, a null check on onPrepareOptionsMenu(), just in case android can screw us up still :( :(

Comment 20

[Sriram Ramasubramanian [:sriram]]

Attachment: Patch (1/2): Removing the static variable

Instead calling invalidateOptionsMenu, this patch just sets the settings and char_encoding's enabled state as needed.

Comment 21

[Sriram Ramasubramanian [:sriram]]

Attachment: Patch (2/2): OCD

This is rebased on top of the other patch.

Comment 22

[Brad Lassey [:blassey] (use needinfo?)]

Comment on attachment 632829 [details] [diff] [review]
Patch (1/2): Removing the static variable

Review of attachment 632829 [details] [diff] [review]:
-----------------------------------------------------------------

nit of s/sMenu/mMenu, but I'm assuming that's what the second patch does

Comment 23

[Sriram Ramasubramanian [:sriram]]

Attachment: Patch (2/2)

I forgot to do a final export.
This just changes aMenu to mMenu (to avoid compilation error).

Comment 24

[Mark Finkle (:mfinkle) (use needinfo?)]

https://hg.mozilla.org/mozilla-central/rev/34f233d3d770
https://hg.mozilla.org/mozilla-central/rev/880f30ecdf6b

Comment 25

[Brad Lassey [:blassey] (use needinfo?)]

small sample size, but so far no crashes with this signature since these patches landed.

Looking at this query:
https://crash-stats.mozilla.com/report/list?range_value=7&range_unit=days&date=2012-06-14&signature=java.lang.NullPointerException%3A%20at%20org.mozilla.gecko.GeckoApp.onPrepareOptionsMenu%28GeckoApp.java%29&version=FennecAndroid%3A16.0a1

Comment 27

[Brad Lassey [:blassey] (use needinfo?)]

Comment on attachment 632829 [details] [diff] [review]
Patch (1/2): Removing the static variable

[Triage Comment]

[Triage Comment]

Please land this on mozilla-aurora, the default branch on mozilla-beta and the beta 7 release branch on mozilla-beta

Comment 28

[Brad Lassey [:blassey] (use needinfo?)]

Comment on attachment 632857 [details] [diff] [review]
Patch (2/2)

[Triage Comment]

Please land this on mozilla-aurora, the default branch on mozilla-beta and the beta 7 release branch on mozilla-beta

Comment 29

[Sriram Ramasubramanian [:sriram]]

Pushed to mozilla-aurora:
https://hg.mozilla.org/releases/mozilla-aurora/rev/e35bdfa9ae87
https://hg.mozilla.org/releases/mozilla-aurora/rev/13356f42a487

Comment 30

[Sriram Ramasubramanian [:sriram]]

Pushed to mozilla-beta:
https://hg.mozilla.org/releases/mozilla-beta/rev/4bb7d443db27
https://hg.mozilla.org/releases/mozilla-beta/rev/158cf6d2d4d8

Comment 31

[Sriram Ramasubramanian [:sriram]]

Aaand.. Pushed to mozilla-beta7:
https://hg.mozilla.org/releases/mozilla-beta/rev/754669d179b1
https://hg.mozilla.org/releases/mozilla-beta/rev/f837956285d5

Comment 32

[Adrian Tamas (:AdrianT)]

Removing qawanted because the patches for the issue have landed

Comment 33

[Sriram Ramasubramanian [:sriram]]

Backed out of beta7 release branch:
https://hg.mozilla.org/releases/mozilla-beta/rev/ee231e3a1d6d

Comment 34

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Looks like this patch has resolved the issue : 
https://crash-stats.mozilla.com/report/list?range_value=7&range_unit=days&date=2012-06-14&signature=java.lang.NullPointerException%3A%20at%20org.mozilla.gecko.GeckoApp.onPrepareOptionsMenu%28GeckoApp.java%29&version=FennecAndroid%3A16.0a1

Comment 35

[Scoobidiver (away)]

There are still crashes in Nightly, 15.0a2 and 14.0b8.

(In reply to Naoki Hirata :nhirata from comment #34)
> Looks like this patch has resolved the issue : 
Hiding crashes happening after the patch landed is not the good way to check a crash is fixed.

Comment 36

[Mark Finkle (:mfinkle) (use needinfo?)]

I think we should file a new bug for this. Too much stuff already in this one, including code that has landed everywhere.

Comment 38

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

(In reply to Scoobidiver from comment #35)
> There are still crashes in Nightly, 15.0a2 and 14.0b8.
> 
> (In reply to Naoki Hirata :nhirata from comment #34)
> > Looks like this patch has resolved the issue : 
> Hiding crashes happening after the patch landed is not the good way to check
> a crash is fixed.

Your sentence confuses me.  It's not hiding if the fix no longer happens in trunk.
Perhaps I should have marked status-firefox14, 15.

It seems to have been fixed in trunk and AFAIK, the main bug being marked is for trunk.

Comment 39

[Scoobidiver (away)]

(In reply to Naoki Hirata :nhirata from comment #38)
> Your sentence confuses me.  It's not hiding if the fix no longer happens in
> trunk. Perhaps I should have marked status-firefox14, 15.
Your query in comment 34 contains a cutoff date, so every crashes happening after this date, ie June 14, are not displayed while the patch landed in 16.0a1/20120614.

The right query should have been: https://crash-stats.mozilla.com/report/list?version=FennecAndroid%3A16.0a1&range_value=4&range_unit=weeks&signature=java.lang.NullPointerException%3A%20at%20org.mozilla.gecko.GeckoApp.onPrepareOptionsMenu%28GeckoApp.java%29
As you can see there are still crashes up to 16.0a1/20120619.
This crash is probably fixed but by another patch we don't know and maybe not uplifted to Aurora and Beta.

Comment 40

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Fair point.  I missed that in the query, it wasn't intentional.

Comment 41

[Scoobidiver (away)]

(In reply to Scoobidiver from comment #39)
> This crash is probably fixed but by another patch we don't know and maybe
> not uplifted to Aurora and Beta.
In fact, it has been replaced by bug 766861 from 16.0a1/20120620.