Closed Bug 1358888 Opened 4 years ago Closed 4 years ago

Crash in java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Number at org.mozilla.gecko.util.GeckoBundle.getInt(GeckoBundle.java)

Categories

(Firefox for Android Graveyard :: General, defect)

Unspecified
Android
defect
Not set
critical

Tracking

(firefox-esr52 unaffected, firefox53 unaffected, firefox54 unaffected, firefox55+ fixed)

RESOLVED FIXED
Firefox 55
Tracking Status
firefox-esr52 --- unaffected
firefox53 --- unaffected
firefox54 --- unaffected
firefox55 + fixed

People

(Reporter: Sylvestre, Assigned: ahunt)

References

Details

(Keywords: crash, reproducible, topcrash)

Crash Data

Attachments

(1 file)

The top crash (by far) on nightly

java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Number
	at org.mozilla.gecko.util.GeckoBundle.getInt(GeckoBundle.java:212)
	at org.mozilla.gecko.BrowserApp.handleMessage(BrowserApp.java:1818)
	at org.mozilla.gecko.EventDispatcher$2.run(EventDispatcher.java:337)
	at android.os.Handler.handleCallback(Handler.java:815)
	at android.os.Handler.dispatchMessage(Handler.java:104)
	at android.os.Looper.loop(Looper.java:192)
	at android.app.ActivityThread.main(ActivityThread.java:5784)
	at java.lang.reflect.Method.invoke(Native Method)
	at java.lang.reflect.Method.invoke(Method.java:372)
	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1084)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:850)


https://crash-stats.mozilla.com/signature/?product=FennecAndroid&version=55.0a1&signature=java.lang.ClassCastException%3A%20java.lang.String%20cannot%20be%20cast%20to%20java.lang.Number%20at%20org.mozilla.gecko.util.GeckoBundle.getInt%28GeckoBundle.java%29&date=%3E%3D2017-04-16T13%3A08%3A48.000Z&date=%3C2017-04-23T13%3A08%3A48.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_sort=-date&page=1#summary
Sebastian, Snorp, can you help?
Thanks
Flags: needinfo?(snorp)
Flags: needinfo?(s.kaspari)
I was able to repro this on my Nexus 6 simply by installing HTTPS Everywhere. Every time you type in the URL bar you crash.
Keywords: reproducible
[Tracking Requested - why for this release]:

This has 627 occurrences on Nightly 20170421135915, which is 90% of all crashes in that build!

If we can work out the regressing change it should be backed out ASAP.
100% of crashes (aggregations->add addons) have the flyweb addon installed.

(That doesn't imply causation though.)

It looks like the crash is reproducible with only https everywhere for me:

1. Installed uBlock origin -> no issues (menu item is added to the main app menu)
2. Installed "copy profile" addon -> no issues (menu item is added to the tools submenu)
3. Enabled flyweb (about:config -> flyweb -> toggle) -> no issues (menu item added to the bottom of the  menu)
4. Installed https everywhere, restarted -> crash


I did a "clear data", followed by:
1. Installed https everyerwhere -> crash again


(I'm going to debug using nightly with https everywhere, but it seems possible that https everywhere is supplying a string for "parent" which we then can't parse on the java side, causing a crash.)
This regression is in fact caused by:
https://hg.mozilla.org/mozilla-central/rev/753e71053540
(Bug 1331742 )

That patch changes menu.add() (in browser.js) to return a uuid for a newly created menu, instead of an int.

Addons, such as https everywhere, store the id returned by menu.add():
https://github.com/EFForg/https-everywhere/blob/445df151702555218cda70aab9aff092f1bfd214/src/chrome/content/code/AndroidUI.jsm#L109
and use that as the "parent" for their new menu items:
https://github.com/EFForg/https-everywhere/blob/445df151702555218cda70aab9aff092f1bfd214/src/chrome/content/code/AndroidUI.jsm#L59

Addon code then uses that uuid (which used to be an int) when adding children to their menu. That fails/throws the exception we're getting at:
https://dxr.mozilla.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/BrowserApp.java#1818

(That same id is used to remove the menu item, but we've already crashed the app well before then, so that isn't even an issue.)
Assignee: nobody → ahunt
I have a quick and dirty fix for this. I can try to improve on it once I'm less jetlagged (i.e. tomorrow morning), but it seems wise to land this fix ASAP to avoid crashing a bunch of nightly users (AFAICT this is a startup crash, which probably inflates the numbers a bit if people are repeatedly and desperately restarting fennec).

That said, any users affected by this will probably have to reinstall nightly manually since they won't get as far as seeing the updater.

(I wonder if we could add a second backup update activity that minimises the amount of other code it calls to allow nightly users to fetch updates precisely in such startup-permacrash situations? I don't know what dependencies the updater code has and/or if it needs gecko though...)
Flags: needinfo?(snorp)
Flags: needinfo?(s.kaspari)
Note also: Bug 1331742 landed 3 days ago, which is when these crash reports started. (The commit is slightly misleading in that it was created 25 days ago, and the web interface only shows that date and not the date a patch really landed.)
Depends on: 1331742
Comment on attachment 8860799 [details]
Bug 1358888 - Update submenu insertion logic to handle UUID

https://reviewboard.mozilla.org/r/132768/#review135666
Attachment #8860799 - Flags: review?(s.kaspari) → review+
backed out Bug 1331742 and retriggered the fennec nightlys
Tracking 55+.
(In reply to Andrzej Hunt :ahunt from comment #7)

> That said, any users affected by this will probably have to reinstall
> nightly manually since they won't get as far as seeing the updater.

Well I wonder if this prevents the automatic background check for updates and download from working.  If it does we should maybe figure out someway to have it install a safe-mode instance when you install the download so you more easily run with add-ons disabled.
But it also seems like we have a missing test for the ability to load and add-on that customizes a menu.
No crash reports with builds created since the backing out of Bug 1331742, hence marking as resolved. (I already added comments there regarding what's needed to fix.)

I've filed Bug 1359730 to look at safer updating, I've got no idea about the feasibility of that though.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.