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

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Robert Kaiser]

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

Comment 1

[Scoobidiver (away)]

There are 8 crashes in 14.0a1/20120419.

Comment 2

[Sriram Ramasubramanian [:sriram]]

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.

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

QA - Let's try to get more details here.

Sriram - Can you look for any possible causes? Best guess?

Comment 4

[Aaron Train [:aaronmt]]

Haven't seen this one in particular.

Comment 5

[Sriram Ramasubramanian [:sriram]]

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.

Comment 6

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

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?

Comment 7

[Mark Finkle (:mfinkle) (use needinfo?)]

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

Comment 8

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

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

Comment 9

[Scoobidiver (away)]

There are 265 crashes in 14.0b1 making it #1 top crasher.

Comment 10

[Mark Finkle (:mfinkle) (use needinfo?)]

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

Comment 11

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

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

Comment 12

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

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

Comment 13

[Mark Finkle (:mfinkle) (use needinfo?)]

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

Comment 14

[Scoobidiver (away)]

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

Comment 15

[Brad Lassey [:blassey] (use needinfo?)]

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

Comment 16

[Scoobidiver (away)]

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

Comment 17

[Mark Finkle (:mfinkle) (use needinfo?)]

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.

Comment 18

[Robert Kaiser]

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.

Comment 19

[Jeff Muizelaar [:jrmuizel]]

Attachment: Maybe this will help

It doesn't seem obvious how the current code could fail, but this fixes one of the possible ways.

Comment 20

[JP Rosevear [:jpr]]

This accounts for almost 10% of b3 crashes.

Comment 21

[Mark Finkle (:mfinkle) (use needinfo?)]

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

Comment 22

[Jeff Muizelaar [:jrmuizel]]

Attachment: only set isRegistered if registering succeeded

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?

Comment 23

[Lucas Rocha (:lucasr)]

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?

Comment 24

[Jeff Muizelaar [:jrmuizel]]

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

[Mark Finkle (:mfinkle) (use needinfo?)]

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

Comment 26

[Chris Peterson [:cpeterson]]

This crash is our #1 topcrash for 14.0b3 by a large margin.

Comment 28

[Jeff Muizelaar [:jrmuizel]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/adf106921f31

Comment 29

[Tony Chung [:tchung]]

Numbers through today - 5-22 to 05-29:

beta 3: 9.67% (top crash)
- https://crash-stats.mozilla.com/topcrasher/byversion/FennecAndroid/14.0b3/7

Aurora: 3.36% (top crash)
- https://crash-stats.mozilla.com/topcrasher/byversion/FennecAndroid/14.0a2/7

Comment 30

[JP Rosevear [:jpr]]

Comment on attachment 627959 [details] [diff] [review]
only set isRegistered if registering succeeded

[Triage Comment]

Comment 31

[Mark Finkle (:mfinkle) (use needinfo?)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/0802aa10b673

Comment 32

[Phil Ringnalda (:philor)]

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.

Comment 33

[Jeff Muizelaar [:jrmuizel]]

I pushed the bustage fix to Aurora now as well:
https://hg.mozilla.org/integration/mozilla-inbound/rev/8b641fa20aed
https://hg.mozilla.org/releases/mozilla-aurora/rev/0802aa10b673

Comment 34

[Tony Chung [:tchung]]

Jeff, et al, 
any tips on where QA can focus on for regression testing  for this patch?

Comment 35

[Mark Finkle (:mfinkle) (use needinfo?)]

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

Comment 37

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/8b641fa20aed

Comment 38

[Ed Morley [:emorley]]

and https://hg.mozilla.org/mozilla-central/rev/adf106921f31

Comment 39

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

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.

Comment 40

[Cristian Nicolae (:xti)]

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

Comment 41

[JP Rosevear [:jpr]]

I see crashes on the 5/30 aurora nightly.  Should this be re-opened?

Comment 42

[Cristian Nicolae (:xti)]

(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

Comment 43

[Scoobidiver (away)]

The fix landed on m-c in 15.0a1/20120530101840 and there are crashes in this build.

Comment 44

[Cristian Nicolae (:xti)]

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

Comment 45

[JP Rosevear [:jpr]]

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

Comment 46

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 47

[Scoobidiver (away)]

(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

Comment 48

[Scoobidiver (away)]

It's #3 top crasher in 14.0b5 with 7.9% of all crashes.

Comment 49

[Mark Finkle (:mfinkle) (use needinfo?)]

Attachment: silence the failure

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.

Comment 50

[Kartikaya Gupta (email:[e-mail])]

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

Comment 51

[Mark Finkle (:mfinkle) (use needinfo?)]

https://hg.mozilla.org/mozilla-central/rev/cf4face65451

opened bug 761706 for finding a better fix.

Comment 52

[Mark Finkle (:mfinkle) (use needinfo?)]

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

Comment 53

[Alex Keybl [:akeybl]]

Comment on attachment 630196 [details] [diff] [review]
silence the failure

[Triage Comment]
betaN+ blocker, approving for all branches

Comment 54

[Mark Finkle (:mfinkle) (use needinfo?)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/cb0dd1e5b5b5
https://hg.mozilla.org/releases/mozilla-beta/rev/c82fa60618a2

Comment 55

[Catalin Suciu [:csuciu]]

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)

Comment 56

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Too early to tell on Socorro whether or not this has been completely fixed.  Will double check next week.

Comment 57

[Mark Finkle (:mfinkle) (use needinfo?)]

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

Comment 58

[Chris Peterson [:cpeterson]]

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.

Comment 59

[Scoobidiver (away)]

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