Closed Bug 744850 Opened 8 years ago Closed 8 years ago

java.lang.IllegalArgumentException: Receiver not registered: org.mozilla.gecko.GeckoConnectivityReceiver@<addr>: at android.app.LoadedApk.forgetReceiverDispatcher(LoadedApk.java)

Categories

(Firefox for Android :: General, defect, critical)

ARM
Android
defect
Not set
critical

Tracking

()

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

People

(Reporter: kairo, Assigned: lucasr)

References

Details

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

Crash Data

Attachments

(2 files, 1 obsolete file)

This bug was filed from the Socorro interface and is 
report bp-622aa6f5-5391-4c98-8a7f-20e6b2120411 .
============================================================= 

java.lang.IllegalArgumentException: Receiver not registered: org.mozilla.gecko.GeckoConnectivityReceiver@415bab40
	at android.app.LoadedApk.forgetReceiverDispatcher(LoadedApk.java:628)
	at android.app.ContextImpl.unregisterReceiver(ContextImpl.java:1066)
	at android.content.ContextWrapper.unregisterReceiver(ContextWrapper.java:354)
	at org.mozilla.gecko.GeckoConnectivityReceiver.unregisterFor(GeckoConnectivityReceiver.java:92)
	at org.mozilla.gecko.GeckoApp.onApplicationPause(GeckoApp.java:2135)
	at org.mozilla.gecko.GeckoApplication.onActivityPause(GeckoApplication.java:43)
	at org.mozilla.gecko.GeckoActivity.onPause(GeckoActivity.java:24)
	at android.app.Activity.performPause(Activity.java:4563)
	at android.app.Instrumentation.callActivityOnPause(Instrumentation.java:1195)
	at android.app.ActivityThread.performPauseActivity(ActivityThread.java:2693)
	at android.app.ActivityThread.performPauseActivity(ActivityThread.java:2662)
	at android.app.ActivityThread.handlePauseActivity(ActivityThread.java:2640)
	at android.app.ActivityThread.access$800(ActivityThread.java:123)
	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1154)
	at android.os.Handler.dispatchMessage(Handler.java:99)
	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)


Crashes with this "java.lang.IllegalArgumentException: Receiver not registered: org.mozilla.gecko.GeckoConnectivityReceiver@<address>: at android.app.LoadedApk.forgetReceiverDispatcher(LoadedApk.java)" signature have been common recently but they never appear at the top because the address changes all the time.

The crash linked in this comment is from yesterday's build.

More such signatures from the recent time are found here:
https://crash-stats.mozilla.com/query/query?product=FennecAndroid&version=FennecAndroid%3A14.0a1&query_search=signature&query_type=contains&query=org.mozilla.gecko.GeckoConnectivityReceiver&do_query=1
Whiteboard: [native-crash]
There are 8 crashes in 14.0a1/20120419.
blocking-fennec1.0: --- → ?
Whiteboard: [native-crash] → [native-crash][startupcrash]
Assignee: nobody → sriram
blocking-fennec1.0: ? → +
What exactly is the scenario for this crash?

In the code, I have guarded checks for not unregistering without registering.
The only scenarios such a crash would happen is this:
1. The receiver is registered for mAppContext1.
2. Something changes with the app changing the context to mAppContext2.
3. We don't register with mAppContext2.
4. We try to unregister with mAppContext1 on onApplicationPause().

If we can find when exactly this context change happens, we can unregister for old context and register for new context.
QA - Let's try to get more details here.

Sriram - Can you look for any possible causes? Best guess?
Keywords: qawanted
Haven't seen this one in particular.
One possible scenario I can think of is, the application getting restarted somehow. Probably a locale change can do it. But it's a separate bigger issue to tackle.
The only thing I can think of that causes restart for fennec currently without locales (since we can't do that on native) is crash reporter with the restart button.  Addons are all restartless I think?
(In reply to Naoki Hirata :nhirata from comment #6)
> The only thing I can think of that causes restart for fennec currently
> without locales (since we can't do that on native) is crash reporter with
> the restart button.  Addons are all restartless I think?

Not true. Fennec Native supports all types of add-ons. The biggest difference is that XUL overlays are not used to modify the UI.
Keywords: qawanted
Whiteboard: [native-crash][startupcrash] → [native-crash][startupcrash], strwanted
(In reply to Sriram Ramasubramanian [:sriram] from comment #2)
> What exactly is the scenario for this crash?
> 
> In the code, I have guarded checks for not unregistering without registering.
> The only scenarios such a crash would happen is this:
> 1. The receiver is registered for mAppContext1.
> 2. Something changes with the app changing the context to mAppContext2.
> 3. We don't register with mAppContext2.
> 4. We try to unregister with mAppContext1 on onApplicationPause().
> 
> If we can find when exactly this context change happens, we can unregister
> for old context and register for new context.

Hrm.  Thinking of things, how about something like a flash webpage for mAppcontext1... then going to a flash webpage on another tab, and sleeping the phone?
Depends on: 726385
There are 265 crashes in 14.0b1 making it #1 top crasher.
Keywords: topcrash
(In reply to Scoobidiver from comment #9)
> There are 265 crashes in 14.0b1 making it #1 top crasher.

Really? Got a link? I can't find the list.
I don't believe that it's that high for 14.0b1, considering beta 1 was just released officially as of yesterday.  It has 60 crashes, making it the 4th ranking crash bug.
https://crash-stats.mozilla.com/topcrasher/byversion/FennecAndroid/14.0b1/1/browser
(you have to add up the totals of looking for receiver)


Even for a 4 weeks result all across FennecAndroid, it doesn't show 265 crashes:
https://crash-stats.mozilla.com/query/query?product=FennecAndroid&version=ALL%3AALL&range_value=4&range_unit=weeks&date=05%2F16%2F2012+21%3A43%3A54&query_search=signature&query_type=contains&query=java.lang.IllegalArgumentException%3A+Receiver+not+registered&reason=&build_id=&process_type=any&hang_type=any&do_query=1
https://crash-analysis.mozilla.com/rkaiser/2012-05-15/2012-05-15.fennecandroid.beta.14.0.devices.html

Looking at this, devices include:
HTC Desire
HTC One X
LGE LG-P930
LGE LG-P999
Motorola Droid 2
Motorola Droid X
NEC N-06C
Samsung GT-I9000 (Samsung Galaxy S II)
Samsung GT-I9100
Samsung GT-I9100 P
Samsung GT-N7000
Samsung Galaxy Nexus
Samsung Galaxy X
Samsung Nexus S
Samsung Nexus S 4G
Samsung SGH-I717
Samsung SHW-M250K
Samsung SPH-D700
Samsung Sprint Galaxy Nexus CDMA
Sony Ericsson LT18i
Sony Ericsson ST18i
Supersonic
(In reply to Sriram Ramasubramanian [:sriram] from comment #5)
> One possible scenario I can think of is, the application getting restarted
> somehow. Probably a locale change can do it. But it's a separate bigger
> issue to tackle.

(In reply to Naoki Hirata :nhirata from comment #6)
> The only thing I can think of that causes restart for fennec currently
> without locales (since we can't do that on native) is crash reporter with
> the restart button.  Addons are all restartless I think?

Given that the crash is here:
http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/GeckoConnectivityReceiver.java#92

I don't think a restart is causing the problem. I think it could be the original activity getting destroyed and a new one being created, which we try to unregister... but we never registered with it. Maybe we just wrap the code in a try/cacth and move on.

Side Issue: We unregister the connectivity receiver in onApplicationPause, but we unregister the batter receiver in onDestroy. Why? We probably use onApplicationPause/Resume to save battery life. But are we seeing similar crashes for the batter receiver? If we did move the battery receiver to use pause/resume, would it also start crashing too?
(In reply to Mark Finkle (:mfinkle) from comment #10)
> (In reply to Scoobidiver from comment #9)
> > There are 265 crashes in 14.0b1 making it #1 top crasher.
> Really? Got a link? I can't find the list.
There are now 501 crashes: https://crash-stats.mozilla.com/query/query?product=FennecAndroid&version=FennecAndroid%3A14.0b1&range_value=1&range_unit=weeks&query_search=signature&query_type=contains&query=LoadedApk&do_query=1
501 crashes out of 1650 ones means 30% of all crashes!

(In reply to Naoki Hirata :nhirata from comment #11)
> I don't believe that it's that high for 14.0b1, considering beta 1 was just
> released officially as of yesterday.  It has 60 crashes, making it the 4th
> ranking crash bug.
> https://crash-stats.mozilla.com/topcrasher/byversion/FennecAndroid/14.0b1/1/
> browser
This link is updated once a day at 7H UTC.
Crash Signature: [@ java.lang.IllegalArgumentException: Receiver not registered: org.mozilla.gecko.GeckoConnectivityReceiver@415bab40: at android.app.LoadedApk.forgetReceiverDispatcher(LoadedApk.java)] → [@ java.lang.IllegalArgumentException: Receiver not registered: org.mozilla.gecko.GeckoConnectivityReceiver@88888888: at android.app.LoadedApk.forgetReceiverDispatcher(LoadedApk.java)]
Hardware: All → ARM
Ryan is seeing this on his phone everytime the app goes into the background. In addition to that, he can't load any pages. These two things might be related and caused by:

D/GeckoAwesomeBar( 1259): creating awesomebar
I/GeckoViewsFactory( 1259): Creating custom Gecko view: AwesomeBar$AwesomeBarEditText
I/GeckoViewsFactory( 1259): Creating custom Gecko view: AwesomeBarTabs
D/GeckoAwesomeBarTabs( 1259): Creating AwesomeBarTabs
D/GeckoAwesomeBarTabs( 1259): Creating All Pages tab
D/GeckoAwesomeBarTabs( 1259): Creating Bookmarks tab
D/GeckoAwesomeBarTabs( 1259): Creating History tab
I/GeckoAwesomeBarTabs( 1259): Got cursor in 11ms
D/dalvikvm(  362): GC_FOR_ALLOC freed 71K, 2% free 13696K/13959K, paused 19ms
I/ActivityManager(  194): Displayed org.mozilla.firefox_beta/org.mozilla.gecko.AwesomeBar: +377ms
W/SurfaceTexture(  118): [SurfaceView] cancelBuffer: SurfaceTexture has been abandoned!
D/OpenGLRenderer( 1259): Flushing caches (mode 0)
D/dalvikvm(  362): GC_CONCURRENT freed 84K, 2% free 14051K/14279K, paused 2ms+2ms
I/GeckoApp( 1259): stop
I/GeckoApp( 1259): destroy
D/GeckoFavicons( 1259): Closing Favicons database
E/ActivityThread( 1259): Activity org.mozilla.firefox_beta.App has leaked IntentReceiver org.mozilla.gecko.GeckoConnectivityReceiver@4179d030 that was originally registered here. Are you missing a call to unregisterReceiver()?
E/ActivityThread( 1259): android.app.IntentReceiverLeaked: Activity org.mozilla.firefox_beta.App has leaked IntentReceiver org.mozilla.gecko.GeckoConnectivityReceiver@4179d030 that was originally registered here. Are you missing a call to unregisterReceiver()?
E/ActivityThread( 1259): 	at android.app.LoadedApk$ReceiverDispatcher.<init>(LoadedApk.java:763)
E/ActivityThread( 1259): 	at android.app.LoadedApk.getReceiverDispatcher(LoadedApk.java:567)
E/ActivityThread( 1259): 	at android.app.ContextImpl.registerReceiverInternal(ContextImpl.java:1043)
E/ActivityThread( 1259): 	at android.app.ContextImpl.registerReceiver(ContextImpl.java:1030)
E/ActivityThread( 1259): 	at android.app.ContextImpl.registerReceiver(ContextImpl.java:1024)
E/ActivityThread( 1259): 	at android.content.ContextWrapper.registerReceiver(ContextWrapper.java:341)
E/ActivityThread( 1259): 	at org.mozilla.gecko.GeckoConnectivityReceiver.registerFor(GeckoConnectivityReceiver.java:85)
E/ActivityThread( 1259): 	at org.mozilla.gecko.GeckoApp.initialize(GeckoApp.java:1710)
E/ActivityThread( 1259): 	at org.mozilla.gecko.GeckoApp.onWindowFocusChanged(GeckoApp.java:1969)
E/ActivityThread( 1259): 	at com.android.internal.policy.impl.PhoneWindow$DecorView.onWindowFocusChanged(PhoneWindow.java:2366)
E/ActivityThread( 1259): 	at android.view.View.dispatchWindowFocusChanged(View.java:5735)
E/ActivityThread( 1259): 	at android.view.ViewGroup.dispatchWindowFocusChanged(ViewGroup.java:851)
E/ActivityThread( 1259): 	at android.view.ViewRootImpl.handleMessage(ViewRootImpl.java:2557)
E/ActivityThread( 1259): 	at android.os.Handler.dispatchMessage(Handler.java:99)
E/ActivityThread( 1259): 	at android.os.Looper.loop(Looper.java:137)
E/ActivityThread( 1259): 	at android.app.ActivityThread.main(ActivityThread.java:4424)
E/ActivityThread( 1259): 	at java.lang.reflect.Method.invokeNative(Native Method)
E/ActivityThread( 1259): 	at java.lang.reflect.Method.invoke(Method.java:511)
E/ActivityThread( 1259): 	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784)
E/ActivityThread( 1259): 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551)
E/ActivityThread( 1259): 	at dalvik.system.NativeStart.main(Native Method)
D/dalvikvm(  362): GC_FOR_ALLOC freed 146K, 2% free 14096K/14343K, paused 23ms
I/dalvikvm-heap(  362): Grow heap (frag case) to 15.041MB for 1278736-byte allocation
D/dalvikvm(  362): GC_CONCURRENT freed 6K, 2% free 15338K/15623K, paused 1ms+2ms
(In reply to Scoobidiver from comment #14)
> 501 crashes out of 1650 ones means 30% of all crashes!
I meant crash signatures instead of crashes.
In volume, it's lower but high enough to be #1 top crasher in 14.0b2: 335 crashes out of 5015, i.e. 6.7% of all crashes.
No longer depends on: 726385
Blocks: 726385
No longer blocks: 726385
Depends on: 726385
Spreading out the blocker load.

Lucas - See if you can reproduce at all. In comment 15, Brad mentions that "Ryan" can reproduce this fairly easily. I assume Ryan is someone in the London office since Brad was in London when he made the comment.
Assignee: sriram → lucasr.at.mozilla
Crash Signature: [@ java.lang.IllegalArgumentException: Receiver not registered: org.mozilla.gecko.GeckoConnectivityReceiver@88888888: at android.app.LoadedApk.forgetReceiverDispatcher(LoadedApk.java)] → [@ java.lang.IllegalArgumentException: Receiver not registered: org.mozilla.gecko.GeckoConnectivityReceiver@<addr>: at android.app.LoadedApk.forgetReceiverDispatcher(LoadedApk.java)]
Summary: java.lang.IllegalArgumentException: Receiver not registered: org.mozilla.gecko.GeckoConnectivityReceiver@<address>: at android.app.LoadedApk.forgetReceiverDispatcher(LoadedApk.java) → java.lang.IllegalArgumentException: Receiver not registered: org.mozilla.gecko.GeckoConnectivityReceiver@<addr>: at android.app.LoadedApk.forgetReceiverDispatcher(LoadedApk.java)
Crash Signature: [@ java.lang.IllegalArgumentException: Receiver not registered: org.mozilla.gecko.GeckoConnectivityReceiver@<addr>: at android.app.LoadedApk.forgetReceiverDispatcher(LoadedApk.java)] → [@ java.lang.IllegalArgumentException: Receiver not registered: org.mozilla.gecko.GeckoConnectivityReceiver@<addr>: at android.app.LoadedApk.forgetReceiverDispatcher(LoadedApk.java]
Crash Signature: [@ java.lang.IllegalArgumentException: Receiver not registered: org.mozilla.gecko.GeckoConnectivityReceiver@<addr>: at android.app.LoadedApk.forgetReceiverDispatcher(LoadedApk.java] → [@ java.lang.IllegalArgumentException: Receiver not registered: org.mozilla.gecko.GeckoConnectivityReceiver@<addr>: at android.app.LoadedApk.forgetReceiverDispatcher(LoadedApk.java) ]
After bug 726385 was deployed for Socorro this week, this signature now reports in as #2 on 14.0b2 data from yesterday and therefore the #1 unfixed crash.
Attached patch Maybe this will help (obsolete) — Splinter Review
It doesn't seem obvious how the current code could fail, but this fixes one of the possible ways.
Attachment #627804 - Flags: feedback?(lucasr.at.mozilla)
This accounts for almost 10% of b3 crashes.
Comment on attachment 627804 [details] [diff] [review]
Maybe this will help

GeckoBatteryManager uses the same pattern. We should change that one too
http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/GeckoBatteryManager.java#47

Turns out we have the same crash for GeckoBatteryManager in bug 758537
Attachment #627804 - Flags: feedback?(lucasr.at.mozilla) → feedback+
I'm not sure who is the best reviewer for this patch. I'm also not sure what the implications of having registerReciever fail are. i.e. do we depend on it working elsewhere?
Attachment #627804 - Attachment is obsolete: true
Attachment #627959 - Flags: review?(mark.finkle)
Comment on attachment 627804 [details] [diff] [review]
Maybe this will help

Review of attachment 627804 [details] [diff] [review]:
-----------------------------------------------------------------

Looks like a good thing to try.

::: mobile/android/base/GeckoConnectivityReceiver.java
@@ +50,4 @@
>  
>      public void registerFor(Activity activity) {
>          if (!isRegistered) {
> +            // registerReciever will return null if registering throws a RemoteException

I couldn't find in the docs where this RemoteException could be thrown. Did you see that in Android's source code?
Attachment #627804 - Attachment is obsolete: false
Attachment #627804 - Flags: review+
(In reply to Lucas Rocha (:lucasr) from comment #23)
> Comment on attachment 627804 [details] [diff] [review]
> Maybe this will help
> 
> Review of attachment 627804 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Looks like a good thing to try.
> 
> ::: mobile/android/base/GeckoConnectivityReceiver.java
> @@ +50,4 @@
> >  
> >      public void registerFor(Activity activity) {
> >          if (!isRegistered) {
> > +            // registerReciever will return null if registering throws a RemoteException
> 
> I couldn't find in the docs where this RemoteException could be thrown. Did
> you see that in Android's source code?

Yes, I saw it in the source code.
Comment on attachment 627959 [details] [diff] [review]
only set isRegistered if registering succeeded

>diff --git a/mobile/android/base/GeckoBatteryManager.java b/mobile/android/base/GeckoBatteryManager.java
>index c109981..3b034a7 100644
>+          // registerReciever will return null if registering throws a RemoteException
>+          isRegistered = activity.registerReceiver(this, filter) != null;

The comment makes it seem like we should try/catch the code, but any RemoteException is already handled in registerReceiver. 

Can we use a simpler, more general comment?

            // registerReciever will return null if registering fails
Attachment #627959 - Flags: review?(mark.finkle) → review+
This crash is our #1 topcrash for 14.0b3 by a large margin.
Duplicate of this bug: 759290
Comment on attachment 627959 [details] [diff] [review]
only set isRegistered if registering succeeded

[Triage Comment]
Attachment #627959 - Flags: approval-mozilla-aurora+
Which is why you *always* want to mention every single cset you push for a bug in that bug, because without https://hg.mozilla.org/integration/mozilla-inbound/rev/8b641fa20aed it burns like inbound burned and like aurora is now burning.
Jeff, et al, 
any tips on where QA can focus on for regression testing  for this patch?
(In reply to Tony Chung [:tchung] from comment #34)
> Jeff, et al, 
> any tips on where QA can focus on for regression testing  for this patch?

The crash itself is not reproducible, so you can't focus too much on that aspect. The connectivity and battery managers were touched by the code, so one idea is to load http://paulrouget.com/mwc-demos/apis/ and view the battery level on the page. It's handled using the BatteryManager. Move Fennec to background and then foreground. Check the webapi page again to see if the battery level is right-ish. Look for errors in the console. Look for "Registering receiver failed" in the log too.
Duplicate of this bug: 758537
https://hg.mozilla.org/mozilla-central/rev/8b641fa20aed
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 15
Attachment #627804 - Attachment is obsolete: true
Trying to reproduce this using task killer and letting the wifi die; also trying to have it switch networks from wireless to using the phone network.
I cannot reproduce this crash on the latest Nightly and Beta build. I followed the suggestions from comment #35 and comment #39 but Fennec worked fine. Also no related errors were thrown in console. Closing bug as verified fixed on:

Firefox 15.0a1 (2012-05-31)
Firefox 14.0b4 (2012-05-31)

Device: Samsung Galaxy Nexus
OS: Android 4.0.2
Status: RESOLVED → VERIFIED
I see crashes on the 5/30 aurora nightly.  Should this be re-opened?
(In reply to JP Rosevear [:jpr] from comment #41)
> I see crashes on the 5/30 aurora nightly.  Should this be re-opened?

The fix was pushed to aurora since 05/29 (comment #33). Is it possible to have crashes on 05/30, but from older aurora builds? I saw yesterday a case like this for a crash with recent reports, but older builds. If is not this case, I guess that we should reopen it
The fix landed on m-c in 15.0a1/20120530101840 and there are crashes in this build.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(In reply to Scoobidiver from comment #43)
> The fix landed on m-c in 15.0a1/20120530101840 and there are crashes in this
> build.

Indeed, crashes are in the build from 05/30, but according to comment #37 and comment #38 the patch was pushed to m-c on 05/30, so today's Nightly build should be fine. At least I wasn't able to reproduce this crash on it.
(In reply to Scoobidiver from comment #43)
> The fix landed on m-c in 15.0a1/20120530101840 and there are crashes in this
> build.

Based on comment #38, I'm not sure it is in that build - is 10:18:40 in GMT or PDT?
This crash:
https://crash-stats.mozilla.com/report/index/ab20c509-410a-4948-b3a1-11b0d2120530

has a build id of 20120530042008 which corresponds to http://hg.mozilla.org/releases/mozilla-aurora/rev/89176b6d643c which contains the 'fix'.

So this has indeed not been fixed.
(In reply to JP Rosevear [:jpr] from comment #45)
> Based on comment #38, I'm not sure it is in that build - is 10:18:40 in GMT
> or PDT?
It's PDT. But 8b641fa20aed and adf106921f31 changesets are before 7c3cd4824f94 (see ftp://ftp.mozilla.org/pub/mobile/nightly/2012-05-30-10-18-40-mozilla-central-android/fennec-15.0a1.multi.android-arm.txt): http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=1+week+ago&enddate=now
It's #3 top crasher in 14.0b5 with 7.9% of all crashes.
The next attempt to stop the bleeding is to just ignore the exception and stop the crash.

We should continue to look for a better fix, which we could take for Fx15.
Attachment #630196 - Flags: review?(bugmail.mozilla)
Comment on attachment 630196 [details] [diff] [review]
silence the failure

Review of attachment 630196 [details] [diff] [review]:
-----------------------------------------------------------------

::: mobile/android/base/GeckoBatteryManager.java
@@ +54,5 @@
>        if (isRegistered) {
> +          try {
> +              activity.unregisterReceiver(this);
> +          } catch (IllegalArgumentException iae) {
> +              Log.e(LOGTAG, "Unregistering receiver failed");

Add iae to the list of parameters? Having the stack trace in the event log might be handy if it changes and/or to spot it more easily in logcats.

::: mobile/android/base/GeckoConnectivityReceiver.java
@@ +64,5 @@
>          if (isRegistered) {
> +            try {
> +                activity.unregisterReceiver(this);
> +            } catch (IllegalArgumentException iae) {
> +                Log.e(LOGTAG, "Unregistering receiver failed");

Ditto
Attachment #630196 - Flags: review?(bugmail.mozilla) → review+
https://hg.mozilla.org/mozilla-central/rev/cf4face65451

opened bug 761706 for finding a better fix.
Status: REOPENED → RESOLVED
Closed: 8 years ago8 years ago
Resolution: --- → FIXED
blocking-fennec1.0: + → betaN+
Target Milestone: Firefox 15 → Firefox 16
Comment on attachment 630196 [details] [diff] [review]
silence the failure

[Approval Request Comment]
Bug caused by (feature/regressing bug #): ?
User impact if declined: Lots of crashes
Testing completed (on m-c, etc.): barely any
Risk to taking this patch (and alternatives if risky): low
String or UUID changes made by this patch: none
Attachment #630196 - Flags: approval-mozilla-beta?
Attachment #630196 - Flags: approval-mozilla-aurora?
Comment on attachment 630196 [details] [diff] [review]
silence the failure

[Triage Comment]
betaN+ blocker, approving for all branches
Attachment #630196 - Flags: approval-mozilla-beta?
Attachment #630196 - Flags: approval-mozilla-beta+
Attachment #630196 - Flags: approval-mozilla-aurora?
Attachment #630196 - Flags: approval-mozilla-aurora+
I cannot reproduce this crash on the latest builds using the suggestions from comment #35 and comment #39. Didn't see any "Registering receiver failed" related errors either. 

Verified on:
Nightly 16.0a1 (2012-06-07)
Aurora 15.0a2 (2012-06-07)
Firefox 14.0b6 Build 1

Device: Samsung Galaxy SII (2.3.4)
Too early to tell on Socorro whether or not this has been completely fixed.  Will double check next week.
(In reply to Naoki Hirata :nhirata from comment #56)
> Too early to tell on Socorro whether or not this has been completely fixed. 
> Will double check next week.

Anything yet?
Lucas, does crash bug 760392 look like fallout from this bug fix?

Curiously, I see Socorro crash reports for bug 760392 on Firefox 14, Beta 15, and Aurora 16 but not Nightly 17.
(In reply to Mark Finkle (:mfinkle) from comment #57)
> (In reply to Naoki Hirata :nhirata from comment #56)
> > Too early to tell on Socorro whether or not this has been completely fixed. 
> > Will double check next week.
> Anything yet?
There are still crashes in the ghost Aurora channel, 14.0a2/20120808 for instance. We should force an update to 16.0a2.
You need to log in before you can comment on or make changes to this bug.