crash in java.lang.IllegalStateException: stateLabelString must not be null at org.mozilla.gecko.fxa.authenticator.AndroidFxAccount.getState(AndroidFxAccount.java)

REOPENED
Assigned to

Status

()

P5
normal
REOPENED
5 years ago
2 months ago

People

(Reporter: aaronmt, Assigned: nalexander)

Tracking

(Depends on: 1 bug, {crash, leave-open})

Firefox 29
Firefox 38
All
Android
crash, leave-open
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox31 wontfix, firefox32 affected, firefox33 affected, firefox34 affected, firefox35 affected, firefox36 affected, firefox37 affected, firefox38 affected, firefox39 affected, fennec+)

Details

(Whiteboard: [workaround: delete account], crash signature)

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
This bug was filed from the Socorro interface and is 
report bp-5884a69b-a8f2-415d-8427-8eb842140127.
=============================================================

ava.lang.IllegalStateException: stateLabelString must not be null
	at org.mozilla.gecko.fxa.authenticator.AndroidFxAccount.getState(AndroidFxAccount.java:342)
	at org.mozilla.gecko.fxa.activities.FxAccountStatusActivity.refresh(FxAccountStatusActivity.java:191)
	at org.mozilla.gecko.fxa.activities.FxAccountStatusActivity.refresh(FxAccountStatusActivity.java:213)
	at org.mozilla.gecko.fxa.activities.FxAccountStatusActivity.onResume(FxAccountStatusActivity.java:163)
	at android.app.Instrumentation.callActivityOnResume(Instrumentation.java:1202)
	at android.app.Activity.performResume(Activity.java:5361)
	at android.app.ActivityThread.performResumeActivity(ActivityThread.java:2816)
	at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:2855)
	at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2300)
	at android.app.ActivityThread.access$700(ActivityThread.java:150)
	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1280)
	at android.os.Handler.dispatchMessage(Handler.java:99)
	at android.os.Looper.loop(Looper.java:175)
	at android.app.ActivityThread.main(ActivityThread.java:5279)
	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:1102)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:869)
	at dalvik.system.NativeStart.main(Native Method)


lolAndroid
(Reporter)

Updated

5 years ago
Component: General → Android Sync
Product: Firefox for Android → Android Background Services
(Reporter)

Comment 1

5 years ago
Think we should get a crash-signature for Android Background Services :)

Stripped from product change

[@ java.lang.IllegalStateException: stateLabelString must not be null at org.mozilla.gecko.fxa.authenticator.AndroidFxAccount.getState(AndroidFxAccount.java)]
(Assignee)

Comment 2

5 years ago
Nah, this is us.  It's a corrupt Account on disk, and little error checking since this has been under construction.  Basically, delete account and begin again and we shouldn't see this.

Comment 3

5 years ago
Managed to reproduce using HTC One X (Android 4.1.1);
I think the account I used is not corrupt because I can successfully login and use the account on other devices.
Flaviu: that's not what Nick means by "corrupt"; there's a bundle of account data on the phone, and that's what's corrupt. That you can log in and use the account on other devices proves the point.

The only reason I'd be concerned about this bug is if you signed in on this phone very recently, or we're seeing lots of these crashes. If your account is a few weeks old, then I chalk this up to "QA risk".
Severity: critical → normal
Priority: -- → P2
Whiteboard: [workaround: delete account]
This feels like it's related to Bug 1046285.
status-firefox31: --- → affected
status-firefox32: --- → affected
tracking-fennec: --- → ?

Updated

4 years ago
Assignee: nobody → nalexander
tracking-fennec: ? → +
(Assignee)

Comment 7

4 years ago
I spent some more time thinking about this, and my best guess is that we're hitting bugs like http://stackoverflow.com/a/11696961.

It's as if our account state isn't being written by setUserData, although we have no real way of knowing if that's the case or if we have legitimate corrupt data being produced.

If my hunch is correct, I have no ideas on how to work around this, save for maintaining our own in-memory cache of the Account state, and only falling back to the Android Account's cache when we haven't populated our own.  We write using setUserData each update but avoid the possibly buggy getUserData.
Just updating the status flags -- this is currently the #3 crash in Firefox for Android 35.0a1.
status-firefox31: affected → wontfix
status-firefox33: --- → affected
status-firefox34: --- → affected
status-firefox35: --- → affected
Keywords: topcrash-android-armv7
(Assignee)

Comment 9

4 years ago
We're currently at an eye-popping 5 crashes per 100ADI on Android 35.0a1.  That's a five alarm fire to me.
Status: NEW → ASSIGNED
I agree that this is urgent, but for the record: that doesn't mean 5%. We'll get one crash per sync, potentially dozens per day, for affected users. 

Sucks hard for those folks, though.
Duplicate of this bug: 1090332
(Assignee)

Updated

4 years ago
Duplicate of this bug: 1090352
(Reporter)

Updated

4 years ago
Duplicate of this bug: 1108680

Comment 14

4 years ago
Hi, Nick:
In our Chinese local market, we received a lot of complains about sync crashes.

I made a crash search and found out most devices are produced by Chinese manufacturer such as Xiaomi, Lenovo.

Do you happen to know if there's a plan to fix it? 

More detailed information, please refer to 

https://crash-stats.mozilla.com/report/list?signature=java.lang.IllegalStateException%3A+stateLabelString+must+not+be+null+at+org.mozilla.gecko.fxa.authenticator.AndroidFxAccount.getState%28AndroidFxAccount.java%29&product=FennecAndroid

Click on "Mobile Devices" on the page.
Flags: needinfo?(nalexander)
(Assignee)

Updated

4 years ago
Duplicate of this bug: 1046285
(Assignee)

Comment 16

4 years ago
(In reply to xshen from comment #14)
> Hi, Nick:
> In our Chinese local market, we received a lot of complains about sync
> crashes.
> 
> I made a crash search and found out most devices are produced by Chinese
> manufacturer such as Xiaomi, Lenovo.
> 
> Do you happen to know if there's a plan to fix it? 

There is no concrete plan, partly because there has been no strong signal that this is worth spending time on.  I outline a work-around in https://bugzilla.mozilla.org/show_bug.cgi?id=964854#c7.

I don't think a quick work-around will take long, I'll try to get to it.  In the interim, can you help me understand how many crashes we're really getting, and trying to figure out how many actual users are seeing this crash?  Lots of the crash reports are clearly the same device, but crash-stats is pretty awful and I can't "group" crash reports by devices.
Flags: needinfo?(nalexander) → needinfo?(xshen)
(Assignee)

Comment 17

4 years ago
Created attachment 8562243 [details] [review]
Link to Github pull-request: https://github.com/mozilla-services/android-sync/pull/532

rnewman: here are a couple of small patches to shed light, perhaps, on caching issues, and then to work around Android caching by doing it ourselves.  The caching logic itself could use your attention, since it's easy to make a mistake.

This would make any caching read issues less frequent, but if we really have bad data on disk we would see the issues just the same.
Attachment #8562243 - Flags: review?(rnewman)

Comment 18

4 years ago
(In reply to Nick Alexander :nalexander from comment #16)
Nick: 
Thanks for your quick response. It's really helpful to improve users' experience if it's fixed.

In the crash-stats I provided(it's a 7-day report till Feb 11th,2015), we can see:
"Crashes per install" average rate is 1.9 , so it's about 404 installations seeing this crash in our local market(see below).

Sync users in China are about 8000, it means 5% Chinese Sync users are affected by this bug. 

=======================================
Here's the detail calculation:
Version   crashes  installations  rate 
35.0.1    999      526            1.9
35.0      725      417            1.7 

Brand     crashes  installations                 
XiaoMi    510      510/1.9 = 270  
LENOVO    254      254/1.9 = 134   
CN market                    404
=======================================
Flags: needinfo?(xshen)
https://hg.mozilla.org/mozilla-central/rev/c4265d0b3fbf
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
status-firefox38: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 38
status-firefox36: --- → affected
status-firefox37: --- → affected

Comment 21

4 years ago
according to user feedback on sumo the issue still persists with current firefox 38 aurora & 39 nightly builds: https://support.mozilla.org/en-US/questions/1048946#answer-698773
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Updated

4 years ago
status-firefox38: fixed → affected
status-firefox39: --- → affected

Comment 22

3 years ago
Is it related to 64bit processor architecture used by some phones like ZOPO ZP720 ?

http://www.mediatek.com/en/products/mobile-communications/smartphone1/mt67321/

My last crash : https://crash-stats.mozilla.com/report/index/47c1f50c-220d-466b-811b-c5cb92150525
(Assignee)

Comment 23

3 years ago
url:        https://hg.mozilla.org/integration/fx-team/rev/078576757615b9c4841814a40d7f1d35b87524e5
changeset:  078576757615b9c4841814a40d7f1d35b87524e5
user:       Nick Alexander <nalexander@mozilla.com>
date:       Fri Jun 19 10:50:34 2015 -0700
description:
Bug 964854 - Reveal cause of exception. r=rnewman

This fixes an oversight from Bug 1042929, which neglected to push the
underlying exception cause through to the final exception.
(Assignee)

Comment 24

3 years ago
An update on this and related tickets, like Bug 1138943.  ncroiset has helped me do a lot of debugging, and the result is that, on some devices, org.json.simple just completely fails to parse JSON.  org.json parses it just fine.

It is possible that ncroiset's guess about 64-bit processor architecture is accurate; it's quite hard to tell from the crash dumps (or even having the device on hand!) if there's a pattern in the device fingerprints.

I don't have an offending device -- I might try to get one for this ticket -- but the path ahead probably looks like removing org.json.simple from the android-sync (and therefore Fennec) codebases entirely.  That will be a separate ticket and will require some investigation, since we have a JUnit 4 test suite that will need to be massaged to use org.json.
Keywords: leave-open
(Assignee)

Updated

3 years ago
Depends on: 1182193
Depends on: 1204559

Updated

3 years ago
Crash Signature: [@ java.lang.IllegalStateException: stateLabelString must not be null at org.mozilla.gecko.fxa.authenticator.AndroidFxAccount.getState(AndroidFxAccount.java)] → [@ java.lang.IllegalStateException: stateLabelString must not be null at org.mozilla.gecko.fxa.authenticator.AndroidFxAccount.getState(AndroidFxAccount.java)] [@ java.lang.IllegalStateException: stateLabelString must not be null at org.mozilla.gecko.fxa.…

Comment 26

3 years ago
I sent the screenshots of CPU-z to Nick just now.

Updated

3 years ago
Duplicate of this bug: 1146526

Comment 28

a year ago
Bumping this way down in priority; only one crash reported in a while, and it's on v33.
Priority: P2 → P5

Updated

a year ago
Product: Android Background Services → Firefox for Android
Not a top crash anymore.
Keywords: topcrash-android-armv7
Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195

Needinfo :susheel if you think this bug should be re-triaged.
You need to log in before you can comment on or make changes to this bug.