Closed Bug 850318 Opened 9 years ago Closed 9 years ago
ANR in Gecko
App Shell .get Clipboard Text(Gecko App Shell .java:1164)
ANR in GeckoAppShell.getClipboardText(GeckoAppShell.java:1164) Steps to Reproduce: i) Visit http://www.neowin.net/news/techspot-tomb-raider-gpu-and-cpu-performance ii) Rotate device to landscape (for whatever reason portrait is unaffected) iii) Long-tap and hold on the URL bar 100% reproducible, at least on this particular device (Alcatel One Touch 903 (ARMv6)) ----- pid 1238 at 2013-03-12 18:42:35 ----- Cmd line: org.mozilla.fennec DALVIK THREADS: (mutexes: tll=0 tsl=0 tscl=0 ghl=0 hwl=0 hwll=0) "main" prio=5 tid=1 WAIT | group="main" sCount=1 dsCount=0 obj=0x4002a310 self=0xcf68 | sysTid=1238 nice=0 sched=0/0 cgrp=[n/a] handle=-1345006496 | schedstat=( 25913823126 33004040809 40585 ) at java.lang.Object.wait(Native Method) - waiting on <0x4002a3a8> (a java.lang.VMThread) at java.lang.Thread.parkFor(Thread.java:1460) at java.lang.LangAccessImpl.parkFor(LangAccessImpl.java:79) at sun.misc.Unsafe.park(Unsafe.java:368) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:188) at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:458) at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:359) at java.util.concurrent.SynchronousQueue.take(SynchronousQueue.java:893) at org.mozilla.gecko.GeckoAppShell.getClipboardText(GeckoAppShell.java:1164) at org.mozilla.gecko.BrowserToolbar$3.onCreateContextMenu(BrowserToolbar.java:186) -- Nightly (03/12) Alcatel One Touch 903 (ARMv6)
getClipboardText assumes it's getting called from a non-UI thread given that it does the whole post/SynchronousQueue thing. But here we are, calling it from the UI thread.
Also reproducible on the Alcatel One Touch 990 (ARMv6, Gingerbread).
(In reply to Kartikaya Gupta (email:firstname.lastname@example.org) from comment #1) > getClipboardText assumes it's getting called from a non-UI thread given that > it does the whole post/SynchronousQueue thing. But here we are, calling it > from the UI thread. Oh wait, I was wrong. getHandler() returns the background thread handler, not the UI thread handler. So the code is actually fine in terms of correctness, but the background thread was probably doing some long-running operation that took more than 5 seconds, and so the UI thread triggered the ANR.
AaronMT, can you check to see if the try build at https://tbpl.mozilla.org/?tree=Try&rev=3501027520e2 (once it's ready) fixes the problem?
The panda M-7 failure on the try build seems to indicate a bug in the patch :( I'll try to debug it.
This should make it so that if getClipboardText() is called on the UI thread it won't block on the background thread (which could be doing some long-running operation). Also if it's called on the background thread then it shouldn't deadlock itself. Try push is green https://tbpl.mozilla.org/?tree=Try&rev=fed0e2ebe1f4 Note this patch depends on the changes in bug 802130 which I just landed to inbound
Attachment #725337 - Flags: review?(wjohnston) → review+
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 22
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.