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

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Sylvestre Ledru [:Sylvestre]]

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

Comment 1

[Sylvestre Ledru [:Sylvestre]]

Sebastian, Snorp, can you help?
Thanks

Comment 2

[Jan Henning [:JanH]]

The crash happens in our (add-on) menu item handler (https://dxr.mozilla.org/mozilla-central/rev/9550eedc0bd80d404dab4e42660c629cc705c16c/mobile/android/base/java/org/mozilla/gecko/BrowserApp.java#1818), so possibly similar/related to bug 1354911?

Comment 3

[Marcia Knous [:marcia]]

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.

Comment 4

[Nicholas Nethercote [inactive]]

[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.

Comment 5

[Andrzej Hunt :ahunt]

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.)

Comment 6

[Andrzej Hunt :ahunt]

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.)

Comment 7

[Andrzej Hunt :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...)

Comment 8

[Andrzej Hunt :ahunt]

Attachment: Bug 1358888 - Update submenu insertion logic to handle UUID

Bug 1331742 updated menu item insertion to use/return UUIDs for menu item ids
(in place of integers). Unfortunately, submenu item insertion wasn't updated
and still assumed integer ID's. This is a quick patch to fix that.

A better architecture is probably possible - this is a quick and dirty fix
to prevent nightly from crashing for users who have addons installed that
insert items into their own submenu.

Review commit: https://reviewboard.mozilla.org/r/132768/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/132768/

Comment 9

[Andrzej Hunt :ahunt]

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.)

Comment 10

[Sebastian Kaspari (:sebastian; :pocmo)]

Comment on attachment 8860799 [details]
Bug 1358888 - Update submenu insertion logic to handle UUID

https://reviewboard.mozilla.org/r/132768/#review135666

Comment 11

[Carsten Book [:Tomcat]]

backed out Bug 1331742 and retriggered the fennec nightlys

Comment 12

[Marcia Knous [:marcia]]

Tracking 55+.

Comment 13

[Bill Gianopoulos [:WG9s]]

(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.

Comment 14

[Bill Gianopoulos [:WG9s]]

But it also seems like we have a missing test for the ability to load and add-on that customizes a menu.

Comment 15

[Andrzej Hunt :ahunt]

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.