Closed Bug 760267 Opened 9 years ago Closed 9 years ago

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

Categories

(Firefox for Android Graveyard :: General, defect)

14 Branch
ARM
Android
defect
Not set
critical

Tracking

(firefox14 verified, firefox15 verified, firefox16 verified, firefox17 verified, blocking-fennec1.0 +)

VERIFIED FIXED
Firefox 16
Tracking Status
firefox14 --- verified
firefox15 --- verified
firefox16 --- verified
firefox17 --- verified
blocking-fennec1.0 --- +

People

(Reporter: scoobidiver, Assigned: sriram)

References

Details

(Keywords: crash, regression, topcrash, Whiteboard: [native-crash][startupcrash])

Crash Data

Attachments

(2 files, 3 obsolete files)

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
Summary: java.lang.NullPointerException: at org.mozilla.gecko.GeckoApp.onPrepareOptionsMenu(GeckoApp.java) → java.lang.NullPointerException: at org.mozilla.gecko.GeckoApp.onPrepareOptionsMenu(GeckoApp.java) at org.mozilla.gecko.Tabs$2.run(Tabs.java)
Summary: java.lang.NullPointerException: at org.mozilla.gecko.GeckoApp.onPrepareOptionsMenu(GeckoApp.java) at org.mozilla.gecko.Tabs$2.run(Tabs.java) → java.lang.NullPointerException: at org.mozilla.gecko.GeckoApp.onPrepareOptionsMenu(GeckoApp.java) at org.mozilla.gecko.GeckoApp.invalidateOptionsMenu(GeckoApp.java)
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.
Blocks: 753200
blocking-fennec1.0: --- → ?
Keywords: regression, topcrash
We need to look at the fix to determine if we want to just back out the original patch.
Assignee: nobody → sriram
blocking-fennec1.0: ? → +
What all devices are actually having this crash?
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.
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.
85% of crashes happen within one minute.
Keywords: qawanted
Whiteboard: [native-crash] → [native-crash][startupcrash]
(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
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
(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.
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
(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.
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
Tested last evening with a variety of devices all using 14.0b6 and had no luck reproducing this.
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.
Are we sure these are market builds?
*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.
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.
This patch removes the static variable.
Attachment #632805 - Flags: review?(mark.finkle)
Attached patch Patch (2/2): OCD (obsolete) — Splinter Review
This patch renames the member variable to be mXxx.
Also, a null check on onPrepareOptionsMenu(), just in case android can screw us up still :( :(
Attachment #632806 - Flags: review?(mark.finkle)
Instead calling invalidateOptionsMenu, this patch just sets the settings and char_encoding's enabled state as needed.
Attachment #632805 - Attachment is obsolete: true
Attachment #632805 - Flags: review?(mark.finkle)
Attachment #632829 - Flags: review?(blassey.bugs)
Attached patch Patch (2/2): OCD (obsolete) — Splinter Review
This is rebased on top of the other patch.
Attachment #632806 - Attachment is obsolete: true
Attachment #632806 - Flags: review?(mark.finkle)
Attachment #632831 - Flags: review?(blassey.bugs)
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
Attachment #632829 - Flags: review?(blassey.bugs) → review+
Attachment #632831 - Flags: review?(blassey.bugs) → review+
Attached patch Patch (2/2)Splinter Review
I forgot to do a final export.
This just changes aMenu to mMenu (to avoid compilation error).
Attachment #632831 - Attachment is obsolete: true
Attachment #632857 - Flags: review?(mark.finkle)
Attachment #632857 - Flags: review?(mark.finkle) → review+
Duplicate of this bug: 760357
Target Milestone: --- → Firefox 16
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
Attachment #632829 - Flags: approval-mozilla-beta+
Attachment #632829 - Flags: approval-mozilla-aurora+
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
Attachment #632857 - Flags: approval-mozilla-beta+
Attachment #632857 - Flags: approval-mozilla-aurora+
Removing qawanted because the patches for the issue have landed
Keywords: qawanted
Status: RESOLVED → VERIFIED
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.
Status: VERIFIED → REOPENED
Keywords: qawanted
Resolution: FIXED → ---
I think we should file a new bug for this. Too much stuff already in this one, including code that has landed everywhere.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Duplicate of this bug: 767713
(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.
Status: RESOLVED → VERIFIED
(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.
Status: VERIFIED → RESOLVED
Closed: 9 years ago9 years ago
Fair point.  I missed that in the query, it wasn't intentional.
(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.
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.