Closed Bug 730688 Opened 12 years ago Closed 12 years ago

java.lang.RuntimeException: Unable to resume activity {org.mozilla.fennec/org.mozilla.fennec.App}: java.lang.RuntimeException: Failure delivering result ResultInfo{who=null, request=2, result=-1, data=Intent { (has extras) }} to activity {org.mozilla.f...

Categories

(Firefox for Android Graveyard :: General, defect, P1)

Product:
Firefox for Android Graveyard
Component:
General
Version:
13 Branch
Platform:
ARM
Android
Type:
defect

Tracking

(firefox13 affected, firefox14 unaffected, blocking-fennec1.0 -)

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox13 --- affected
firefox14 --- unaffected
blocking-fennec1.0 --- -

People

(Reporter: scoobidiver, Assigned: sriram)

References

Details

(4 keywords, Whiteboard: [native-crash])

Crash Data

It's #1 top crasher in FennecAndroid 13.0a1.
There is a Socorro bug on this - bug 724670. Fix should be out this week.

KaiRo will work on getting some data that makes this more actionable.
Depends on: 724670
The Java exception is:
java.lang.RuntimeException: Unable to resume activity {org.mozilla.fennec/org.mozilla.fennec.App}: java.lang.RuntimeException: Failure delivering result ResultInfo{who=null, request=2, result=-1, data=Intent { (has extras) }} to activity {org.mozilla.fennec/org.mozilla.fennec.App}: java.lang.NullPointerException
	at android.app.ActivityThread.performResumeActivity(ActivityThread.java:2444)
	at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:2472)
	at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1986)
	at android.app.ActivityThread.access$600(ActivityThread.java:123)
	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1147)
	at android.os.Handler.dispatchMessage(Handler.java:99)
	at android.os.Looper.loop(Looper.java:137)
	at org.mozilla.gecko.GeckoApp$35.run(GeckoApp.java:1824)
	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)
Caused by: java.lang.RuntimeException: Failure delivering result ResultInfo{who=null, request=2, result=-1, data=Intent { (has extras) }} to activity {org.mozilla.fennec/org.mozilla.fennec.App}: java.lang.NullPointerException
	at android.app.ActivityThread.deliverResults(ActivityThread.java:2980)
	at android.app.ActivityThread.performResumeActivity(ActivityThread.java:2431)
	... 16 more
Caused by: java.lang.NullPointerException
	at org.mozilla.gecko.BrowserToolbar.setTitle(BrowserToolbar.java:299)
	at org.mozilla.gecko.GeckoApp.loadRequest(GeckoApp.java:2613)
	at org.mozilla.gecko.GeckoApp.onActivityResult(GeckoApp.java:2586)
	at android.app.Activity.dispatchActivityResult(Activity.java:4649)
	at android.app.ActivityThread.deliverResults(ActivityThread.java:2976)
	... 17 more
No longer depends on: 724670
The important part of this stack trace is the rethrown exception at the bottom:

Caused by: java.lang.NullPointerException
	at org.mozilla.gecko.BrowserToolbar.setTitle(BrowserToolbar.java:299)
	at org.mozilla.gecko.GeckoApp.loadRequest(GeckoApp.java:2613)
	at org.mozilla.gecko.GeckoApp.onActivityResult(GeckoApp.java:2586)
	at android.app.Activity.dispatchActivityResult(Activity.java:4649)
	at android.app.ActivityThread.deliverResults(ActivityThread.java:2976)

I think I have seen this NullPointerException when enabling "Settings > Developer options > Don't keep activities", then closing and reopening Fennec.
Most of the reports are on Android 4.0.*, and the first crash appeared on the 17th. bug 727610 sounds suspicious, especially with that NPE on the call to setTitle in BrowserToolbar. CC'ing :sriram
(In reply to Chris Peterson (:cpeterson) from comment #5)
> I think I have seen this NullPointerException when enabling "Settings >
> Developer options > Don't keep activities", then closing and reopening
> Fennec.

Confirming I can reproduce that under ICS (Android 4.0.2) on my Galaxy Nexus. Enable that option, and then visit a site.
blocking-fennec1.0: --- → ?
Keywords: regression, reproducible
There have been no crashes in 13.0a1/20120301 and above.
The working range might be:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=30b4f99a137c&tochange=1c3b291d0830
resolving works for me based on the last comment
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
I can still reproduce this exception and SIGSEGV when I enable "Settings > Developer options > Don't keep activities" and then visit one or two websites:

E/GeckoAppShell(10736): java.lang.RuntimeException: Unable to resume activity {org.mozilla.fennec_cpeterson/org.mozilla.fennec_cpeterson.App}: java.lang.RuntimeException: Failure delivering result ResultInfo{who=null, request=2, result=-1, data=Intent { (has extras) }} to activity {org.mozilla.fennec_cpeterson/org.mozilla.fennec_cpeterson.App}: java.lang.NullPointerException
...
E/GeckoAppShell(10736): Caused by: java.lang.NullPointerException
E/GeckoAppShell(10736): 	at org.mozilla.gecko.BrowserToolbar.setTitle(BrowserToolbar.java:299)
E/GeckoAppShell(10736): 	at org.mozilla.gecko.GeckoApp.loadRequest(GeckoApp.java:2571)
E/GeckoAppShell(10736): 	at org.mozilla.gecko.GeckoApp.onActivityResult(GeckoApp.java:2544)
E/GeckoAppShell(10736): 	at android.app.Activity.dispatchActivityResult(Activity.java:4649)
E/GeckoAppShell(10736): 	at android.app.ActivityThread.deliverResults(ActivityThread.java:2972)
E/GeckoAppShell(10736): 	... 17 more
F/libc    (10736): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1)
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Keywords: topcrash
Keywords: topcrash
Assignee: nobody → jdhaliwal
It first appeared in 13.0a1/20120217. The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a853f4017192&tochange=2271cb92cc05
Assignee: jdhaliwal → sriram
blocking-fennec1.0: ? → +
Priority: -- → P1
From what I've figured out from looking at this, if the issue only occurs from the "Don't keep Activities" developer option being enabled, then we shouldn't be concerned with it, since this crash is only because this option is enabled. This removes the Activity stack and makes it so that only one atomic Activity is active at a time. This would cause an issue with any Activity that requires a result from an Activity that has been pushed on top of the current Activity, then subsequently popped. This happens in fennec at least in one spot: when we bring up the awesome bar, input a URL and return to the webpage activity to load the page.

We should however look into whether onCreate is called upon returning to the webpage activity. We may be able to "recreate" the webpage activity in order for this error to stop.
blocking-fennec1.0: + → ?
Priority: P1 → --
Sorry, perhaps "atomic" is confusing wording. The "Don't keep Activities" option makes it so that a singular activity is shown on the stack at a time (one element "stack").
The "Don't keep Activities" setting makes this exception easier to reproduce, but it is still a valid issue.

This is our #1 or #2 topcrash. I doubt all those users have set "Don't keep Activities" setting (which is not exposed in the UI of earlier Android OS versions).
"Intent.FLAG_ACTIVITY_NO_HISTORY" is the culprit :D

From what Josh mentioned, the activity is popped out -- say when you open Awesomebar, lock the screen and unlock it -- and hence GeckoApp doesnt get any result.

Removing this flag while launching the activity will fix this issue, I guess.
Priority: -- → P1
(In reply to Sriram Ramasubramanian [:sriram] from comment #16)
> "Intent.FLAG_ACTIVITY_NO_HISTORY" is the culprit :D
> 
> From what Josh mentioned, the activity is popped out -- say when you open
> Awesomebar, lock the screen and unlock it -- and hence GeckoApp doesnt get
> any result.
> 
> Removing this flag while launching the activity will fix this issue, I guess.

Let's get a patch soon, so we can test the fix by watching for crash counts to get smaller.
blocking-fennec1.0: ? → beta+
The NPE on setTitle() happens due to this:
As per the option, once we move to AwesomeBar, GeckoApp is killed. And on returning back, GeckoApp is re-created, at which point BrowserToolbar is accessed before it's member variables are initialized.
I/GeckoAwesomeBarTabs( 3067): Got cursor in 22ms
I/ActivityManager(  196): Displayed org.mozilla.fennec_sriramramasubramanian/org.mozilla.gecko.AwesomeBar: +288ms
D/OpenGLRenderer( 3067): Flushing caches (mode 0)
I/GeckoApp( 3067): stop
I/GeckoApp( 3067): destroy
D/GeckoFavicons( 3067): Closing Favicons database
I/WindowManager(  196): createSurface Window{41d56af8 InputMethod paused=false}: DRAW NOW PENDING
D/dalvikvm( 3067): GC_EXPLICIT freed 8497K, 35% free 16645K/25223K, paused 7ms+4ms
E/StrictMode( 3067): class org.mozilla.fennec_sriramramasubramanian.App; instances=2; limit=1
E/StrictMode( 3067): android.os.StrictMode$InstanceCountViolation: class org.mozilla.fennec_sriramramasubramanian.App; instances=2; limit=1
E/StrictMode( 3067): 	at android.os.StrictMode.setClassInstanceLimit(StrictMode.java:1)
D/dalvikvm(  418): GC_FOR_ALLOC freed 1672K, 20% free 15325K/18951K, paused 16ms
I/dalvikvm-heap(  418): Grow heap (frag case) to 16.263MB for 1278736-byte allocation
D/dalvikvm(  418): GC_CONCURRENT freed 43K, 13% free 16529K/18951K, paused 2ms+4ms
D/dalvikvm( 3067): Trying to load lib /data/data/org.mozilla.fennec_sriramramasubramanian/lib/libmozglue.so 0x4182fd58
D/dalvikvm( 3067): Shared lib '/data/data/org.mozilla.fennec_sriramramasubramanian/lib/libmozglue.so' already loaded in same CL 0x4182fd58
W/GeckoApp( 3067): zerdatime 8774740 - onCreate
W/WindowManager(  196): ActivityRecord{41afce08 org.mozilla.fennec_sriramramasubramanian/.App} failed creating starting window
W/WindowManager(  196): android.view.InflateException: Binary XML file line #28: Error inflating class <unknown>

The GeckoApp stops, destroyed and get recreated. The static variables persist during this flow. This makes me feel updateTabCountAndAnimate() crash also has similar reasons.

The same path is observed when changing a locale too.
Static variables are difficult to manage in Android's Activity lifecycle.

If we must have static variables, I think we should have only one, something like a GeckoAppShell singleton instance that holds non-static references to shared/"global" objects.
Crash Signature: data=Intent { (has extras) }} to activity {org.mozilla.f... ] → request=2, result=-1, data=Intent { (has extras) }} to activity ... ] data=Intent { (has extras) }} to activity {org.mozilla.f... ] [@ java.lang.RuntimeException: Unable to resume activity {org.mozilla.fennec_aurora/org.mozilla.fennec_aurora.App}: java.l…
It's #2 unfixed top crasher in 13.0a2.

The latest crash in the trunk happened in 14.0a1/20120321031151. You need to find and back port the patch that fixed it.
The latest crash in Aurora took place in 13.0a2/20120324042010. Maybe, it's also fixed in this channel.
Bug 739789 is the fix for this issue (and others). It is not a simple fix. We might be able to bandaid over the problem for a short-term fix, but I am not confident we'd get the "right & proper" in for Fx13.
Moving to nom to let the drivers know that this bug won't make it in this release given the required fix. If we want to take on the extra risk to the surrounding parts of the affected code, then we can start hammering away at it, but I don't think that it warrants that at this point.
blocking-fennec1.0: beta+ → ?
not blocking since this seems to have been fixed by one of the patches that was uplifted to aurora on the 23rd. Please re-nom if it reappears.
blocking-fennec1.0: ? → -
Let's close it as work for me.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → WORKSFORME
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.