Closed Bug 730890 Opened 12 years ago Closed 12 years ago

crash [@ libdvm.so@<address>]

Categories

(Firefox for Android Graveyard :: General, defect)

Product:
Firefox for Android Graveyard
Component:
General
Version:
13 Branch
Platform:
ARM
Android
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(firefox14 fixed, blocking-fennec1.0 +, fennec+)

Status:
RESOLVED FIXED
Milestone:
Firefox 15
Tracking Flags:
Tracking Status
firefox14 --- fixed
blocking-fennec1.0 --- +
fennec + ---

People

(Reporter: nhirata, Assigned: snorp)

References

Details

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

Crash Data

Attachments

(2 files, 4 obsolete files)

Logcat from crash
44.93 KB, application/zip
Details
Install and run an Android Looper on Gecko main thread
11.35 KB, patch
blassey
: approval-mozilla-aurora+
Details | Diff | Splinter Review 
Some of the devices that this has shown in:

'Transformer Prime TF201'
Transformer TF101
Galaxy Nexus
Product: 'GT-P7510', Manufacturer: 'samsung'
Cannot seem to replicate crash atm.
Crash Signature: [@ libdvm.so@0x50a0e] [@ libdvm.so@0x50e96] [@ libdvm.so@0x50a2a] [@ libdvm.so@0x50de2] [@ libdvm.so@0x51ae6] [@ libdvm.so@0x50e62] [@ libdvm.so@0x5149e] → [@ libdvm.so@0x50a0e] [@ libdvm.so@0x50e96] [@ libdvm.so@0x50a2a] [@ libdvm.so@0x50de2] [@ libdvm.so@0x51ae6] [@ libdvm.so@0x50e62] [@ libdvm.so@0x5149e] [@ libdvm.so@0x50dde]
All these crashes have Crash Address 0xdeadd00d, which is a magic number used by the Dalvik VM to abort itself, typically due an uncaught Java exception. If someone can reproduce this crash, getting `adb logcat` output should contain the uncaught Java exception's stack trace.
Chris, in this case, shouldn't this be a case where we should try to modify our breakpad code in a way that we send the actual Java stack trace in the appropriate field?
Yes, this is worth investigating. We try to catch and report unexpected Java exceptions, but sometimes there are some code paths where our exception handler is not in the call stack. I will open a new bug for that investigation.
-> bug 733434 - Breakpad not reporting uncaught Java exceptions
I'm seeing this crash happening after a while in this case, when clicking on the 'open crash1.htm setinterval then close after 4 seconds' button, using Samsung Galaxy Nexus, Android 4.0.2, you need to have Plugins enabled by default, no no Tap to Play.
http://people.mozilla.org/~mwargers/tests/flashcrash_ics/buttonopencrash1.htm

https://crash-stats.mozilla.com/report/index/bp-6b8e3225-ddd7-49e5-8d53-194fc2120306
From all I've seen, there is some problem we probably only hit on ICS that leads to this signature (once bug 733434 lands we'll get a better and proper signature).

Martijn, any chance you can get logcat as described in comment #4?
STR:
1. Set Fennec -> Settings -> Plugins -> Enabled
2. restart Fennec
3. go to http://people.mozilla.org/~mwargers/tests/flashcrash_ics/buttonopencrash1.htm
4. Select Always Show for popups
5. During the time that it's doing the test, go to menu-> settings

Crash should occur.
Keywords: reproducible
Here is the Java exception for that crash:

 java.lang.RuntimeException: Can't create handler inside thread that has not called Looper.prepare()
 	at android.os.Handler.<init>(Handler.java:121)
 	at android.content.ClipboardManager$2.<init>(ClipboardManager.java:63)
 	at android.content.ClipboardManager.<init>(ClipboardManager.java:63)
 	at android.app.ContextImpl$7.createService(ContextImpl.java:285)
 	at android.app.ContextImpl$ServiceFetcher.getService(ContextImpl.java:198)
 	at android.app.ContextImpl.getSystemService(ContextImpl.java:1176)
 	at android.view.ContextThemeWrapper.getSystemService(ContextThemeWrapper.java:79)
 	at android.app.Activity.getSystemService(Activity.java:3999)
 	at org.mozilla.gecko.GeckoAppShell.nativeRun(Native Method)
 	at org.mozilla.gecko.GeckoAppShell.runGecko(GeckoAppShell.java:447)
 	at org.mozilla.gecko.GeckoThread.run(GeckoThread.java:106)
 JNI WARNING: 0x41927558 is not a valid JNI reference
             in Lorg/mozilla/gecko/GeckoAppShell;.nativeRun:(Ljava/lang/String;)V (GetIntField)
 VM aborting
 Fatal signal 11 (SIGSEGV) at 0xdeadd00d (code=1)


GeckoThread is either calling methods that should only be called from the main UI thread or it needs its own Looper.
Assignee: nobody → blassey.bugs
snorp, sounds like flash is doing clipboard operations on the gecko thread.
Assignee: blassey.bugs → snorp
I am not able to reproduce this crash with the STRs from https://bugzilla.mozilla.org/show_bug.cgi?id=730890#c10/https://bugzilla.mozilla.org/show_bug.cgi?id=730890#c8  removing reproducible.  We need another way to get this crash.
Keywords: reproducible
Just loading http://people.mozilla.org/~mwargers/tests/flashcrash_ics/crash1.htm directly crashes current Fennec Native after a while on my Samsung Galaxy Nexus.
You might have to open and close that unminimized testcase a couple of times.
Martijn, I get a different crash than what this bug lists with opening and closing your test file.  :/
What crash are you getting then? 
I guess Fennec has changed that it has made it a different stacktrace or something.
gfxSharedImageSurface::Open bug 694964
Bug 694964 has landed in m-c.   Martijn, please retest the nightly now, and see if you can reproduce.  Add logs and crash reports if yes.  Thanks!
Still crashing in today's (4-2) trunk build using str from coment 8:
https://crash-stats.mozilla.com/report/index/bp-b04aa667-7292-40aa-a644-068372120402
0 	libdvm.so 	libdvm.so@0x50a2a

Although it took a while before the crash occured (like 1 minute or so).
Ok, I get this crash also with this testcase, which is just a whole lot of Flash plugins: http://people.mozilla.org/~mwargers/tests/plugins/flash/parentframes_flash_alot.html
I get it after that page has been loaded, going back in history, then going forward.
I also got the libgui crash once, this way.
tracking-fennec: --- → +
blocking-fennec1.0: --- → +
I have a fix for this (in theory) that I will post tomorrow.
Comment on attachment 612671 [details] [diff] [review]
Set up an Android Looper on the main Gecko thread

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

rather than override nsBaseAppShell::Run() let's put this in MessagePump::Run() inside an ifdef ANDROID
Attachment #612671 - Flags: review?(blassey.bugs)
Attachment #612671 - Attachment is obsolete: true
Comment on attachment 612799 [details] [diff] [review]
Set up an Android Looper on the main Gecko thread

There are some nits to pick in this patch, but some questions to start
 - this patch as-is isn't correct because nothing signals the main event loop to break out to process new java tasks when they're posted.  That means the android tasks can sit in queue for an unbounded amount of time.

 - this switches processing plugin events from java thread to gecko thread.  Why?  What's the threading model for the plugin code?

 - are the interfaces that flash is using (clipboard here?) safe to use from the gecko thread?  Worried that we'll end up playing whack-a-mole here.

 - relatedly, can we somehow interpose our own Looper implementation that takes tasks attempted to be enqueued on the gecko thread and post them to the java thread?  Or turn them into nsIRunnable/Task* to be run on the gecko thread.
Attachment #612799 - Flags: review?(jones.chris.g)
(In reply to Chris Jones [:cjones] [:warhammer] from comment #26)
> Comment on attachment 612799 [details] [diff] [review]
> Set up an Android Looper on the main Gecko thread
> 
> There are some nits to pick in this patch, but some questions to start
>  - this patch as-is isn't correct because nothing signals the main event
> loop to break out to process new java tasks when they're posted.  That means
> the android tasks can sit in queue for an unbounded amount of time.

While this is true, in practice I don't believe it will be a serious problem, as we're pretty much constantly sending Gecko events for one reason or another. I'm also not really sure we can even solve this, as there is no way to know when the Looper has work to do.

> 
>  - this switches processing plugin events from java thread to gecko thread. 
> Why?  What's the threading model for the plugin code?

http://mxr.mozilla.org/mozilla-central/source/dom/plugins/base/android/android_npapi.h#973

The comment there indicates that postEvent stuff should be called on the gecko main thread, and this was confirmed by people from Adobe. We were just doing it wrong before. The reason we were doing it on the Android UI thread before is because some stuff in the plugin needed a Looper (clipboard, etc).

> 
>  - are the interfaces that flash is using (clipboard here?) safe to use from
> the gecko thread?  Worried that we'll end up playing whack-a-mole here.

Not sure. The plugin is can do anything it wants, so I think we just have to trust that it's doing the correct thing.

> 
>  - relatedly, can we somehow interpose our own Looper implementation that
> takes tasks attempted to be enqueued on the gecko thread and post them to
> the java thread?  Or turn them into nsIRunnable/Task* to be run on the gecko
> thread.

This is something we considered, but it would involve quite a bit of mucking around in private native Android bits. This is something I'm accustomed to doing, but the posted solution seemed easier and less risky.
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #27)
> (In reply to Chris Jones [:cjones] [:warhammer] from comment #26)
> > Comment on attachment 612799 [details] [diff] [review]
> > Set up an Android Looper on the main Gecko thread
> >  - relatedly, can we somehow interpose our own Looper implementation that
> > takes tasks attempted to be enqueued on the gecko thread and post them to
> > the java thread?  Or turn them into nsIRunnable/Task* to be run on the gecko
> > thread.
> 
> This is something we considered, but it would involve quite a bit of mucking
> around in private native Android bits. This is something I'm accustomed to
> doing, but the posted solution seemed easier and less risky.

How much work are we talking to interpose our own Looper?
(In reply to Chris Jones [:cjones] [:warhammer] from comment #28)
> 
> How much work are we talking to interpose our own Looper?
I'm not sure its even possible really. Most of the methods we'd need to override are either final or private. It turns out you can violate those constraints with JNI, but I'm not sure we want to be doing that.

Snorp, what do you think?
(In reply to Brad Lassey [:blassey] from comment #29)
> (In reply to Chris Jones [:cjones] [:warhammer] from comment #28)
> > 
> > How much work are we talking to interpose our own Looper?
> I'm not sure its even possible really. Most of the methods we'd need to
> override are either final or private. It turns out you can violate those
> constraints with JNI, but I'm not sure we want to be doing that.
> 
> Snorp, what do you think?

Yeah, I was trying to determine if it is really feasible. I'm still not so sure. At any rate it's going to be a giant time sink, and I think this patch is Good Enough(tm) for our purposes (which for the most part is to make Flash happy).
If it's possible/feasible, I'd really prefer to hook Looper.  The patch here is touching a part of the code it shouldn't and isn't correct.

Still would like a time estimate --- hours, days, weeks?
So android.os.Looper talks to android.os.MessageQueue to do the actual work, which talks to the native functions defined here: https://github.com/android/platform_frameworks_base/blob/master/core/jni/android_os_MessageQueue.cpp

I think we'd basically need to rewrite that, so at this point my opinion is that it's not possible.
That looks pretty doable but making it interoperate with the non-hooked Loopers across multiple versions looks hard.

Alright, let's go with this approach.
Hmm, I interpreted cjones comment #33 as approval of the patch but I guess he didn't really give it. Chris if you want me to back this out, let me know.
Backed out anyway due to XUL bustage.
This patch also caused a crash in all native Android crashtests/reftests/jsreftests:
https://tbpl.mozilla.org/php/getParsedLog.php?id=10815885&tree=Mozilla-Inbound
Try run for eb703b3c1986 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=eb703b3c1986
Results (out of 58 total builds):
    success: 20
    warnings: 28
    failure: 10
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jwillcox@mozilla.com-eb703b3c1986
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #36)
> Hmm, I interpreted cjones comment #33 as approval of the patch but I guess
> he didn't really give it. Chris if you want me to back this out, let me know.

No, that wasn't r+.  Please request review.
https://hg.mozilla.org/mozilla-central/rev/022be5c50732
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 14
Backed out: https://hg.mozilla.org/mozilla-central/rev/2cd7a0d63346
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Try run for d494bbec3690 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=d494bbec3690
Results (out of 61 total builds):
    success: 18
    warnings: 35
    failure: 8
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jwillcox@mozilla.com-d494bbec3690
Try run for d11b820f6769 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=d11b820f6769
Results (out of 57 total builds):
    success: 19
    warnings: 29
    failure: 9
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jwillcox@mozilla.com-d11b820f6769
 Timed out after 12 hours without completing.
Crash Signature: [@ libdvm.so@0x50a0e] [@ libdvm.so@0x50e96] [@ libdvm.so@0x50a2a] [@ libdvm.so@0x50de2] [@ libdvm.so@0x51ae6] [@ libdvm.so@0x50e62] [@ libdvm.so@0x5149e] [@ libdvm.so@0x50dde] → libdvm.so@0x50e96] [@ libdvm.so@0x50ea2] [@ libdvm.so@0x5149e] [@ libdvm.so@0x51ae6] [@ libdvm.so@0x50806] [@ libdvm.so@0x5087e] [@ libdvm.so@0x50886] [@ libdvm.so@0x5098e] [@ libdvm.so@0x509ce] [@ libdvm.so@0x50a0e] [@ libdvm.so@0x50a2a] [@ lib…
Crash Signature: libdvm.so@0x50e96] [@ libdvm.so@0x50ea2] [@ libdvm.so@0x5149e] [@ libdvm.so@0x51ae6] → libdvm.so@0x50e96] [@ libdvm.so@0x50ea2] [@ libdvm.so@0x5127a] [@ libdvm.so@0x5149e] [@ libdvm.so@0x51ae6]
(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #21)
> Ok, I get this crash also with this testcase, which is just a whole lot of
> Flash plugins:
> http://people.mozilla.org/~mwargers/tests/plugins/flash/
> parentframes_flash_alot.html
> I get it after that page has been loaded, going back in history, then going
> forward.
> I also got the libgui crash once, this way.

04-19-2012 nightly, Galaxy Nexus, Android 4.0.4.

I can reproduce the stack using the testcase above.   
STR:
1) load testpage
2) tap to active plugins
3) when page is done loading, hit system Back button
4) go forward to page again
5) crash stack.

https://crash-stats.mozilla.com/report/index/38c13124-d5aa-4918-972d-78d162120419
I'm also getting this crash with the Galaxy SII with the very simple steps to reproduce in bug 737058.

I think it is very important to fix this before Fennec 1.0, since this is a topcrash and I see this happening on all kinds of sites with Flash.
It's #1 top crasher in FennecAndroid 13.0a2 with 13% of all crashes.
Keywords: reproducible
Originally flagged for blocking1.0+.   But QA feels this could be blocking beta+.   renoming for triage team to re-discuss.
blocking-fennec1.0: + → ?
blocking-fennec1.0: ? → +
Crash Signature: libdvm.so@0x50e96] [@ libdvm.so@0x50ea2] [@ libdvm.so@0x5127a] [@ libdvm.so@0x5149e] [@ libdvm.so@0x51ae6] [@ libdvm.so@0x50806] [@ libdvm.so@0x5087e] [@ libdvm.so@0x50886] [@ libdvm.so@0x5098e] [@ libdvm.so@0x509ce] [@ libdvm.so@0x50a0e] [@ lib… → libdvm.so@0x50dde] [@ libdvm.so@0x50e16] [@ libdvm.so@0x50e56] [@ libdvm.so@0x50e62] [@ libdvm.so@0x50e96] [@ libdvm.so@0x50ea2] [@ libdvm.so@0x51202] [@ libdvm.so@0x5127a] [@ libdvm.so@0x5149e] [@ libdvm.so@0x51ae6] [@ libdvm.so@0x51d66] [@ lib…
Depends on: 747799
Crash Signature: libdvm.so@0x50dde] [@ libdvm.so@0x50e16] [@ libdvm.so@0x50e56] [@ libdvm.so@0x50e62] [@ libdvm.so@0x50e96] [@ libdvm.so@0x50ea2] [@ libdvm.so@0x51202] [@ libdvm.so@0x5127a] [@ libdvm.so@0x5149e] [@ libdvm.so@0x51ae6] [@ libdvm.so@0x51d66] [@ lib… → libdvm.so@0x5149e] [@ libdvm.so@0x51ae6] [@ libdvm.so@0x51d66] libdvm.so@0x50a4e] [@ libdvm.so@0x50de2] [@ libdvm.so@0x50dde] [@ libdvm.so@0x50e16] [@ libdvm.so@0x50e22] [@ libdvm.so@0x50e56] [@ libdvm.so@0x50e62] [@ libdvm.so@0x50e96] [@ libdvm…
Target Milestone: Firefox 14 → ---
I can sort of reproduce this with http://www.iex.nl/ and have that loaded some time in the background, while the phone's screen is turned off.
This is on the Samsung Galaxy Nexus and I didn't have Flash turned on on that site.

So I guess this crash isn't Flash related only.

https://crash-stats.mozilla.com/report/index/bp-ca1996d5-3d12-446d-af7a-0db962120427
0 	libdvm.so 	libdvm.so@0x50a2a 	
1 	libstlport.so 	libstlport.so@0x3327a

I tried to get to reproduce this with this testcase:
http://people.mozilla.org/~mwargers/tests/forms/formautosubmit_parentframes.htm
Because I thought it might have something to do with submitting forms in iframes. I crashed once with that, but afterwards, I didn't.
mw22, libdvm.so is a Dalvik VM library, so many unrelated JNI crashes or uncaught exceptions may crash in libdvm.so.
Comment on attachment 619078 [details] [diff] [review]
Install and run an Android Looper on Gecko main thread

You should file a followup bug and leave a "FIXME/bug XXXXXX" comment
somewhere in this patch documenting that plugin tasks don't wake up
the Gecko event loop, so they can be stranded for an unbounded amount
of time.  Not because we need to fix it immediately, but to leave a
trail of breadcrumbs for some poor schmuck who ends up debugging that
kind pf symptom in the future.

>diff -r 7b04b6bc7e4e -r 27eb48f377eb ipc/glue/MessagePump.cpp

>+#ifdef MOZ_WIDGET_ANDROID
>+    AndroidBridge::Bridge()->PumpMessageLoop();
>+#endif
>+

This prioritizes plugin tasks over IPC messages, which isn't what we
want.  Please move this below the DoWork()/if statements below.

>     did_work |= aDelegate->DoWork();
>     if (!keep_running_)
>       break;

>diff -r 7b04b6bc7e4e -r 27eb48f377eb mobile/android/base/GeckoAppShell.java

>+    public static void pumpMessageLoop() {
>+        // We're going to run the Looper below, but we need a way to break out, so
>+        // we post this Runnable that causes a divide by zero error. The Runnable
>+        // is added to the end of the queue, so it will be executed after anything
>+        // else that has been added prior.
>+        sGeckoHandler.post(new Runnable() {
>+            public void run() {
>+                int zero = 0;
>+                int foo = 0xdeadbeef / zero;
>+            }

At first it looked to me like you want Looper.quit(), but the docs
seem to imply that a quit looper ignores posted tasks while it's
quitted, so quitting and restarting here (if that's possible) leads to
race conditions when events are posted from elsewhere.  If that was
your analysis, please document that here.

So OK.  Please just |throw new RuntimeException()| here; not really
sure what this code is trying to do.

Would like to see the next version.
Attachment #619078 - Flags: review?(jones.chris.g)
Attachment #619078 - Attachment is obsolete: true
(In reply to Chris Jones [:cjones] [:warhammer] from comment #52)
> Comment on attachment 619078 [details] [diff] [review]
> Install and run an Android Looper on Gecko main thread
> 
> You should file a followup bug and leave a "FIXME/bug XXXXXX" comment
> somewhere in this patch documenting that plugin tasks don't wake up
> the Gecko event loop, so they can be stranded for an unbounded amount
> of time.  Not because we need to fix it immediately, but to leave a
> trail of breadcrumbs for some poor schmuck who ends up debugging that
> kind pf symptom in the future.

Done, bug 750713

> 
> >diff -r 7b04b6bc7e4e -r 27eb48f377eb ipc/glue/MessagePump.cpp
> 
> >+#ifdef MOZ_WIDGET_ANDROID
> >+    AndroidBridge::Bridge()->PumpMessageLoop();
> >+#endif
> >+
> 
> This prioritizes plugin tasks over IPC messages, which isn't what we
> want.  Please move this below the DoWork()/if statements below.

Done.

> 
> >     did_work |= aDelegate->DoWork();
> >     if (!keep_running_)
> >       break;
> 
> >diff -r 7b04b6bc7e4e -r 27eb48f377eb mobile/android/base/GeckoAppShell.java
> 
> >+    public static void pumpMessageLoop() {
> >+        // We're going to run the Looper below, but we need a way to break out, so
> >+        // we post this Runnable that causes a divide by zero error. The Runnable
> >+        // is added to the end of the queue, so it will be executed after anything
> >+        // else that has been added prior.
> >+        sGeckoHandler.post(new Runnable() {
> >+            public void run() {
> >+                int zero = 0;
> >+                int foo = 0xdeadbeef / zero;
> >+            }
> 
> At first it looked to me like you want Looper.quit(), but the docs
> seem to imply that a quit looper ignores posted tasks while it's
> quitted, so quitting and restarting here (if that's possible) leads to
> race conditions when events are posted from elsewhere.  If that was
> your analysis, please document that here.

I added a lengthy explanation of the reasoning to the comment in the current patch.
Attachment #612799 - Attachment is obsolete: true
(In reply to Chris Peterson (:cpeterson) from comment #51)
> mw22, libdvm.so is a Dalvik VM library, so many unrelated JNI crashes or
> uncaught exceptions may crash in libdvm.so.

Ok, I filed bug 750965 for a crash with a similar stack like this then.

The crash that I mentioned in comment 49, I'll file a new bug tomorrow.
Comment on attachment 619918 [details] [diff] [review]
Install and run an Android Looper on Gecko main thread

>diff --git a/mobile/android/base/GeckoAppShell.java b/mobile/android/base/GeckoAppShell.java

>+        // We could throw an exception, but that is difficult because of Java's
>+        // checked type system. We can't add any 'throws' clause that is not in
>+        // the interface definition for run(). We are allowed to throw an Error,
>+        // but that doesn't work well in practice. Android logs a stack trace
>+        // and, at least in some cases, does not even exit the Looper. While ugly,
>+        // the below does have the advantage of working.

This comment is rather misleading ... divide-by-zero throws an
ArithmeticException (IIRC) which is a RuntimeException.
RuntimeException's are unchecked.  Wrt Java semantics here, throwing a
RuntimeException should be equivalent to divide-by-zero.

Are you saying that android logs a stack trace for explicit |throw|
statements, but not for divide-by-zero RuntimeExceptions?  That would
be a reason to divide by zero here, and what this part of the comment
should say (we don't want the stacks logged).  If |throw new
RuntimeException();| behaves like divide-by-zero, which is what I
would assume, then let's use that.

r=me with that sorted
Attachment #619918 - Flags: review?(jones.chris.g) → review+
(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #55)
> The crash that I mentioned in comment 49, I'll file a new bug tomorrow.

I filed bug 751343 for that now.
Attachment #619918 - Attachment is obsolete: true
I seem to remember trying RuntimeException with my very first attempt, but it does in fact seem to work. New patch attached with that change and updated comment.
https://hg.mozilla.org/mozilla-central/rev/2e3b161905ca
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 15
Depends on: 752153
Comment on attachment 620700 [details] [diff] [review]
Install and run an Android Looper on Gecko main thread

[Approval Request Comment]
Regression caused by (bug #): 
User impact if declined: 
Testing completed (on m-c, etc.): 
Risk to taking this patch (and alternatives if risky):
String changes made by this patch:
Attachment #620700 - Flags: approval-mozilla-aurora?
Attachment #620700 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Tried applying this to Aurora, but:

patching file widget/android/AndroidBridge.cpp
Hunk #1 FAILED at 209
1 out of 2 hunks FAILED -- saving rejects to file widget/android/AndroidBridge.cpp.rej
patching file widget/android/AndroidBridge.h
Hunk #2 FAILED at 565
1 out of 2 hunks FAILED -- saving rejects to file widget/android/AndroidBridge.h.rej
patch failed, unable to continue (try -v)
patch failed, rejects left in working dir
errors during apply, please fix and refresh 2e3b161905ca

I didn't want to accidentally mess anything up, so I didn't try unbitrotting.
Issue is still reproducible on:
Build: Aurora 14.0b2 2012-05-17
Device: Samsung Galaxy Nexus
OS: Android 4.0.2

Crash report: https://crash-stats.mozilla.com/report/index/bp-6278832c-acf9-41ac-9136-892182120517

Bug 756068 was logged.
Depends on: 756068
No longer depends on: 756068
No longer blocks: 747787
Depends on: 759146
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: