Closed Bug 731288 Opened 13 years ago Closed 13 years ago

crash @ libgui.so

Categories

(Firefox for Android Graveyard :: General, defect)

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

Tracking

(firefox14 verified, firefox15 verified, blocking-fennec1.0 +)

Status:
VERIFIED FIXED
Tracking Flags:
Tracking Status
firefox14 --- verified
firefox15 --- verified
blocking-fennec1.0 --- +

People

(Reporter: nhirata, Assigned: snorp)

References

Details

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

Crash Data

Attachments

(3 files, 2 obsolete files)

Full raw log (Nightly 05/03)
117.70 KB, text/plain
Details
Valgrind log up to/including crash
152.58 KB, text/plain
Details
Don't call methods on finalized SurfaceTexture, JNI housekeeping
3.26 KB, patch
blassey
: review+
blassey
: approval-mozilla-aurora+
Details | Diff | Splinter Review
This bug was filed from the Socorro interface and is report bp-da221dd7-04b8-49e9-84a6-e0f952120226 . ============================================================= Frame Module Signature [Expand] Source 0 libc.so libc.so@0x12014 1 libgui.so libgui.so@0x1b67f 2 libandroid_runtime.so libandroid_runtime.so@0x6e08d 3 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc @0x7f70e 4 libdvm.so libdvm.so@0x1ec72 5 dalvik-heap (deleted) dalvik-heap @0xe3334e 6 libdvm.so libdvm.so@0x5906b 7 framework.odex framework.odex@0x647ca3 8 libandroid_runtime.so libandroid_runtime.so@0x6e077 9 libdvm.so libdvm.so@0xb2f8e 10 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc @0xbb9e 11 libdvm.so libdvm.so@0x34326 12 dalvik-heap (deleted) dalvik-heap @0xdc1016 13 framework.odex framework.odex@0x20e306 14 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc @0x1b0e 15 libdvm.so libdvm.so@0xb7c56 16 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc @0xbb9e 17 core.odex core.odex@0x21077f 18 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc @0xbb9e 19 libdvm.so libdvm.so@0x6ca9b 20 dalvik-heap (deleted) dalvik-heap @0xf3d4de 21 dalvik-heap (deleted) dalvik-heap @0xfaaf91c 22 dalvik-heap (deleted) dalvik-heap @0x19cffe6 23 libdvm.so libdvm.so@0xb2f8e 24 dalvik-heap (deleted) dalvik-heap @0x19c71be 25 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc @0x7f89e 26 libdvm.so libdvm.so@0xb7c56 27 libdvm.so libdvm.so@0x6cabb 28 libdvm.so libdvm.so@0x603c5 29 dalvik-heap (deleted) dalvik-heap @0x19cdb1e 30 dalvik-heap (deleted) dalvik-heap @0x19cffe6 31 libdvm.so libdvm.so@0x7ab0b 32 dalvik-heap (deleted) dalvik-heap @0x4a646 33 dalvik-heap (deleted) dalvik-heap @0x19c71be 34 dalvik-heap (deleted) dalvik-heap @0x2a6 35 dalvik-heap (deleted) dalvik-heap @0x19cdb1e 36 dalvik-heap (deleted) dalvik-heap @0x2a6 37 dalvik-heap (deleted) dalvik-heap @0xfaaf91c 38 framework.odex framework.odex@0x260256 39 dalvik-heap (deleted) dalvik-heap @0x4a646 40 libdvm.so libdvm.so@0x1edfe 41 libdvm.so libdvm.so@0x30ace 42 libdvm.so libdvm.so@0xb2f8e 43 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc @0x7f89e 44 libdvm.so libdvm.so@0x34326 45 framework.odex framework.odex@0x20e306 46 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc @0xc2a6 47 dalvik-heap (deleted) dalvik-heap @0x19cffe6 48 dalvik-heap (deleted) dalvik-heap @0x19c752e 49 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc @0x7f89e 50 libdvm.so libdvm.so@0xb2f8e 51 dalvik-heap (deleted) dalvik-heap @0x19c320e 52 dalvik-heap (deleted) dalvik-heap @0x19c71ce 53 libdvm.so libdvm.so@0x6c7b7 54 dalvik-heap (deleted) dalvik-heap @0x19c31fe 55 dalvik-heap (deleted) dalvik-heap @0x19c31fe 56 dalvik-heap (deleted) dalvik-heap @0xdc1016 57 dalvik-heap (deleted) dalvik-heap @0x2a6 58 dalvik-heap (deleted) dalvik-heap @0x19c31fe 59 libdvm.so libdvm.so@0x7b4b5 60 libdvm.so libdvm.so@0xb7c56 61 dalvik-heap (deleted) dalvik-heap @0x19c31fe 62 data@app@org.mozilla.fennec-2.apk@classes.dex data@app@org.mozilla.fennec-2.apk@classes.dex@0x918c6 63 libdvm.so libdvm.so@0xb7c56 64 libdvm.so libdvm.so@0x33b46 65 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc @0xacd8e 66 libdvm.so libdvm.so@0x7795f 67 framework.odex framework.odex@0x6de784 68 dalvik-heap (deleted) dalvik-heap @0xfaaf91c 69 dalvik-heap (deleted) dalvik-heap @0xe8e 70 dalvik-heap (deleted) dalvik-heap @0x4a646 71 dalvik-heap (deleted) dalvik-heap @0x19c71be 72 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc @0x7f89e 73 dalvik-heap (deleted) dalvik-heap @0xe3334e 74 dalvik-heap (deleted) dalvik-heap @0x19c31fe 75 dalvik-heap (deleted) dalvik-heap @0x2a6 76 libdvm.so libdvm.so@0x73d3d 77 dalvik-heap (deleted) dalvik-heap @0x2a6 78 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc @0xbe3e 79 core.odex core.odex@0xacb5c 80 dalvik-heap (deleted) dalvik-heap @0x42de 81 libdvm.so libdvm.so@0x1edfe 82 libdvm.so libdvm.so@0x30ace 83 libdvm.so libdvm.so@0xb2f8e 84 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc @0x5d3e 85 libdvm.so libdvm.so@0x34326 86 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc @0x5d3e 87 dalvik-heap (deleted) dalvik-heap @0xdc66ee 88 core.odex core.odex@0x21009b 89 libdvm.so libdvm.so@0x6ca95 90 libdvm.so libdvm.so@0xb2f8e 91 libdvm.so libdvm.so@0xb7c56 92 libdvm.so libdvm.so@0x5fb3f 93 libdvm.so libdvm.so@0x6cabb 94 libdvm.so libdvm.so@0xb7c56 95 libdvm.so libdvm.so@0x5fb3f 96 libdvm.so libdvm.so@0xb2f8e 97 libdvm.so libdvm.so@0x5fbef 98 dalvik-heap (deleted) dalvik-heap @0xfaaf91c 99 libdvm.so libdvm.so@0x5fb3f 100 libc.so libc.so@0x12c1e 101 libc.so libc.so@0x12772 More Reports: https://crash-stats.mozilla.com/report/list?range_value=7&range_unit=days&date=2012-02-28&signature=libgui.so%400x1b67f&version=FennecAndroid%3A13.0a1 On 'Galaxy Nexus', earliest build seen for 13a1: 20120221031301 URLS: http://basketball.fantasysports.yahoo.com/nba/11568/2/editroster
blocking-fennec1.0: --- → -
Crash Signature: [@ libgui.so@0x1b67f] → [@ libgui.so@0x1b67f] [@ libgui.so@0x1bd29 ]
Crash Signature: [@ libgui.so@0x1b67f] [@ libgui.so@0x1bd29 ] → [@ libgui.so@0x1b67f] [@ libgui.so@0x1bd29 ] [@ libgui.so@0x1b849 ]
Crash Signature: [@ libgui.so@0x1b67f] [@ libgui.so@0x1bd29 ] [@ libgui.so@0x1b849 ] → [@ libgui.so@0x1b67f] [@ libgui.so@0x1bd29 ] [@ libgui.so@0x1b849 ] [@ libgui.so@0x1b91d ] [@ libgui.so@0x1b859 ] [@ libgui.so@0x20005 ] [@ libgui.so@0x2090b ]
There are no Fennec components in the stack.
Crash Signature: [@ libgui.so@0x1b67f] [@ libgui.so@0x1bd29 ] [@ libgui.so@0x1b849 ] [@ libgui.so@0x1b91d ] [@ libgui.so@0x1b859 ] [@ libgui.so@0x20005 ] [@ libgui.so@0x2090b ] → [@ libgui.so@0x1b67f] [@ libgui.so@0x1b849] [@ libgui.so@0x1b859] [@ libgui.so@0x1b91d] [@ libgui.so@0x1b92d] [@ libgui.so@0x1bd29] [@ libgui.so@0x1bf1d] [@ libgui.so@0x20005] [@ libgui.so@0x2090b]
Keywords: topcrash
Summary: crash [@ libgui.so@0x1b67f] → crash @ libgui.so
Re-nomming. This appears to affect specifically ICS devices, Naoki can you dig out other possible URLs?
blocking-fennec1.0: - → ?
Keywords: qawanted
I sometimes get this crash while testing, but most of the time I get all of the other crashes.
blocking-fennec1.0: ? → +
I seem to be happening this quite frequently with my galaxy nexus on this url: http://people.mozilla.org/~mwargers/tests/plugins/flash/flashembed_wrappedinlink.html after switching the Plugins pref to disabled, reloading the page, then tapping on the second plugin placeholder 2 times, going back, then setting the plugins pref to enbabled and reloading, etc. Note bug 750790 and bug 738198 on this testcase. I guess bug 738198 might be even related.
Version: Firefox 13 → Trunk
Martjin can you try reproducing this on stock.
Martijn, can you test with those STR with a build from just before bug 712975 landed?
I tried a build from 2012-04-24, which is from before bug 712975, I can also see the crash there. Flipping the pref doesn't seem necessary to get the crash. I just get it by having plugins enabled by default, tapping on the plugin, going back and repeating that a couple of times. (In reply to JP Rosevear [:jpr] from comment #6) > Martjin can you try reproducing this on stock. Not sure what you mean, you mean try and see if stock browser crashes?
Yes, please try the test case in the stock Android browser. We are wondering if this is a crash that we have no control over.
I've tried like 50 times or so on stock browser, but that doesn't crash with the str.
I can reproduce this visiting http://www.iex.nl/ (after the Android app message), and leaving my phone idle for about five minutes. When my screen turns off GeckoAppShell continues to taking whole-screen screenshots, is that right? bp-3e78abb9-a20c-43a3-89df-c6d5e2120503
Keywords: reproducible
Glandium - Can you try to get some data from valgrind that might be helpful to figure this bug out?
Assignee: nobody → mh+mozilla
Julian would be a better candidate for valgrinding. I only have valgrind on a pandaboard, and can't interact with it.
Am happy to valgrind it, but am currently on holiday and won't be within range of suitable hardware until Tuesday morning. I can do it then if that'd help.
removing QA Wanted; aaronmt and mw22 looked at it already
Keywords: qawanted
Assignee: mh+mozilla → jseward
(In reply to Julian Seward from comment #14) > Am happy to valgrind it, but am currently on holiday and won't be > within range of suitable hardware until Tuesday morning. I can do > it then if that'd help. It would. Thanks.
Easier way to reproduce is with this testcase: http://people.mozilla.org/~mwargers/tests/plugins/flash/flashembed_wrappedinlink_back_and_forth.html Make sure you have set Plugins to enabled. I'm seeing this crash stack with the Galaxy Nexus, but with the Galaxy SII, I get this stack:https://crash-stats.mozilla.com/report/index/bp-8d3522fd-7ef6-4339-98a5-4709f2120509 0 libdvm.so JNI_CreateJavaVM 1 libflashplayer.so libflashplayer.so@0x555111 2 libflashplayer.so libflashplayer.so@0x555cc7 3 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc @0x87bc2 4 libflashplayer.so libflashplayer.so@0x6fa12a 5 libflashplayer.so libflashplayer.so@0x75a556 6 libflashplayer.so libflashplayer.so@0x75a556 7 libflashplayer.so libflashplayer.so@0x555bf3
Using http://people.mozilla.org/~mwargers/tests/plugins/flash/flashembed_wrappedinlink_back_and_forth.html it crashes on Memcheck after some minutes, with this showing up close to that point. Look at the failing address -- seems like libflashplayer decided to abort for some reason. Invalid write of size 1 at 0x543EDD6: dvmAbort (Init.cpp:1855) by 0x54203FB: IndirectRefTable::get(void*) const (IndirectRefTable.cpp:179) by 0x5443999: dvmDecodeIndirectRef(Thread*, _jobject*) (Jni.cpp:318) by 0x54467E3: CallObjectMethodV(_JNIEnv*, _jobject*, _jmethodID*, std::__va_list) (Jni.cpp:1958) by 0x2F3FE77D: ??? (in /data/data/com.adobe.flashplayer/lib/libflashplayer.so) Address 0xdeadd00d is not stack'd, malloc'd or (recently) free'd
Complete Valgrind log leading up to the crash. There's quite a bit of noise and the interesting bit is at the end. It looks like libflashplayer.so decided to abort for some reason. I also got a strace-style log (not included here) and looked at it a bit to see if the process ran out of file descriptors, but there's nothing obviously to support that, although file descriptor numbers up to 129 are visible in the log (a bit high?) Probably a complete red herring.
I should add that some of the stack traces are obviously bogus, eg Warning: invalid file descriptor -1 in syscall close() at 0x481B6A8: close (close.S:10) by 0x22C74B91: PR_AtomicDecrement (pratom.c:312) by 0x36410CBB: nsXPConnect::Release() (nsAtomicRefcnt.h:90) .. possibly the ones that start in probable handwritten ARM assembly routines, like close() in this case.
When run natively, this fails in a different way than on Valgrind: there is a java.util.ConcurrentModificationException and then it segfaults. I wonder if the ConcurrentModificationException is somehow related? I/GeckoAppShell(16998): showSurface:Surface(name=null, identity=0) @ x:9 y:98 w:238 h:198 inverted: true blend: true I/GeckoAppShell(16998): showSurface:Surface(name=null, identity=0) @ x:9 y:317 w:238 h:198 inverted: true blend: true W/System.err(16998): java.util.ConcurrentModificationException W/System.err(16998): at java.util.ArrayList$ArrayListIterator.next(ArrayList.java:569) W/System.err(16998): at org.mozilla.gecko.gfx.LayerRenderer$Frame.drawForeground(LayerRenderer.java:674) I/GeckoAppShell(16998): showSurface:Surface(name=null, identity=0) @ x:9 y:536 w:238 h:198 inverted: true blend: true W/System.err(16998): at dalvik.system.NativeStart.run(Native Method) W/System.err(16998): at dalvik.system.NativeStart.run(Native Method) D/dalvikvm(16998): GC_CONCURRENT freed 408K, 7% free 7647K/8199K, paused 8ms+4ms W/Surface (16998): Surface.finalize() has work. You should have called release() (43573168, 0) W/Surface (16998): Surface.finalize() has work. You should have called release() (43676144, 0) F/libc (16998): Fatal signal 11 (SIGSEGV) at 0x000009e0 (code=1)
Based on the above, I am wondering if there is a race on mExtraLayers in LayerRenderer.java, or some similar kind of concurrency problem.
This has significant volume on 14.0b1 now, #5 + #9 + #24 on current topcrash reports for that version right now, summed up it probably would be #1.
Still present in m-c. The complaints in comment #23 re ConcurrentModificationException; I think that's been fixed elsewhere.
That should read "The complaints in comment #23 re ConcurrentModificationException have disappeared;"
Here's where JimDB says it is crashing (repeatably). Note there's no mozilla frames in this. Frame #3 looks bad, as if it is calling SurfaceTexture::abandon() on a null object. Program received signal SIGSEGV, Segmentation fault. warning: Could not load shared library symbols for 3 libraries, e.g. org.mozilla.fennec_sewardj. Use the "info sharedlibrary" command to see the complete listing. Do you need "set solib-search-path" or "set sysroot"? [Switching to Thread 26275] pthread_mutex_lock (mutex=0x9e0) at bionic/libc/bionic/pthread.c:1041 1041 mtype = (mutex->value & MUTEX_TYPE_MASK); (gdb) where #0 pthread_mutex_lock (mutex=0x9e0) at bionic/libc/bionic/pthread.c:1041 #1 0x4076f84a in lock (this=<optimized out>) at frameworks/base/include/utils/threads.h:289 #2 Autolock (mutex=<optimized out>, this=<optimized out>) at frameworks/base/include/utils/threads.h:244 #3 android::SurfaceTexture::abandon (this=0x0) at frameworks/base/libs/gui/SurfaceTexture.cpp:1117 #4 0x401c43fa in ?? () from /home/sewardj/MOZ/moz-gdb/lib/0288504044c06217/system/lib/libandroid_runtime.so #5 0x4080ebf4 in dvmPlatformInvoke () at dalvik/vm/arch/arm/CallEABI.S:258 #6 0x4084930c in dvmCallJNIMethod (args=0x5137bebc, pResult=0x20df980, method=0x56c9fb50, self=0x20df970) at dalvik/vm/Jni.cpp:1155 #7 0x40820a50 in dalvik_mterp () at dalvik/vm/mterp/out/InterpAsm-armv7-a.S:26853 #8 0x4082422c in dvmInterpret (self=0x20df970, method=0x56c9fce0, pResult=<optimized out>) at dalvik/vm/interp/Interp.cpp:1965 #9 0x4085ca2c in dvmInvokeMethod (obj=<optimized out>, method=0x56c9fce0, argList=<optimized out>, params=<optimized out>, returnType=0x40a302a8, noAccessCheck=<optimized out>) at dalvik/vm/interp/Stack.cpp:733 #10 0x40863e8a in Dalvik_java_lang_reflect_Method_invokeNative (args=<optimized out>, pResult=0x20df980) at dalvik/vm/native/java_lang_reflect_Method.cpp:101 #11 0x40820a50 in dalvik_mterp () at dalvik/vm/mterp/out/InterpAsm-armv7-a.S:26853 #12 0x4082422c in dvmInterpret (self=0x20df970, method=0x56c25d40, pResult=<optimized out>) at dalvik/vm/interp/Interp.cpp:1965 #13 0x4085ccfc in dvmCallMethodV (self=0x20df970, method=0x56c25d40, obj=0x41093ea0, fromJni=false, pResult=0x5af28eb8, args=...) at dalvik/vm/interp/Stack.cpp:522 #14 0x4085cd20 in dvmCallMethod (self=0x20df970, method=0x56c25d40, obj=0x41093ea0, pResult=0x0) at dalvik/vm/interp/Stack.cpp:425 #15 0x4084fe40 in interpThreadStart (arg=0x20df970) at dalvik/vm/Thread.cpp:1534 #16 0x400bb190 in __thread_entry (func=0x4084fd91 <interpThreadStart(void*)>, arg=0x20df970, tls=<optimized out>) at bionic/libc/bionic/pthread.c:217 #17 0x400bacc8 in pthread_create (thread_out=<optimized out>, attr=0xbe947944, start_routine=0x4084fd91 <interpThreadStart(void*)>, arg=0x20df970) at bionic/libc/bionic/pthread.c:357 #18 0x00000000 in ?? () (gdb) p mutex $1 = (pthread_mutex_t *) 0x9e0
The source loc for frame #4 above is #4 0x401c43fa in android::SurfaceTexture_release (env=<optimized out>, thiz=<optimized out>) at frameworks/base/core/jni/android/graphics/SurfaceTexture.cpp:239 Seems like this is some problem to do with Surface destruction/release. I noticed this in the system log, just before the fault: W/Surface (27536): Surface.finalize() has work. You should have called release() (43874464, 0) W/Surface (27536): Surface.finalize() has work. You should have called release() (43961696, 0) F/libc (27536): Fatal signal 11 (SIGSEGV) at 0x000009e0 (code=1) Do the comments re Surface.finalize() vs release() mean something to somebody?
(In reply to Julian Seward from comment #30) > The source loc for frame #4 above is > #4 0x401c43fa in android::SurfaceTexture_release (env=<optimized out>, > thiz=<optimized out>) at > frameworks/base/core/jni/android/graphics/SurfaceTexture.cpp:239 > > Seems like this is some problem to do with Surface destruction/release. I > noticed > this in the system log, just before the fault: > > W/Surface (27536): Surface.finalize() has work. You should have called > release() (43874464, 0) > W/Surface (27536): Surface.finalize() has work. You should have called > release() (43961696, 0) > F/libc (27536): Fatal signal 11 (SIGSEGV) at 0x000009e0 (code=1) > > Do the comments re Surface.finalize() vs release() mean something to > somebody? Hmm, interesting. We call SurfaceTexture.release() in the SurfaceTextureLayer finalizer. I think this is wrong, because finalizers can be called in any order. It's possible that the Surface or SurfaceTexture was already finalized, which probably caused the underlying native SurfaceTexture to be destroyed. I'll prepare a patch.
Assignee: jseward → snorp
The patch above should fix the crash, but I haven't been able to reproduce here. This is not really the correct fix, of course, but the proper one is more complicated because of races with plugin/tab destruction.
I tried the patch in comment #32, but it does not appear to fix the crash. These still appear: W/Surface ( 5563): Surface.finalize() has work. You should have called release() (43950064, 0) W/Surface ( 5563): Surface.finalize() has work. You should have called release() (42478192, 0) W/Surface ( 5563): Surface.finalize() has work. You should have called release() (42381008, 0) > but I haven't been able to reproduce here. Enable plugins, then go here: http://people.mozilla.org/~mwargers/tests/plugins/flash/flashembed_wrappedinlink_back_and_forth.html Crashes within seconds. Maybe only fails, or only fails quickly, on a dual core cpu? I am running on dual A9s (Xoom).
Crash Signature: [@ libgui.so@0x1b67f] [@ libgui.so@0x1b849] [@ libgui.so@0x1b859] [@ libgui.so@0x1b91d] [@ libgui.so@0x1b92d] [@ libgui.so@0x1bd29] [@ libgui.so@0x1bf1d] [@ libgui.so@0x20005] [@ libgui.so@0x2090b] → libgui.so@0x205a1] [@ libgui.so@0x206f9] [@ libgui.so@0x2090b] [@ libgui.so@0x20eb1] [@ libgui.so@0x1b67f] [@ libgui.so@0x1b849] [@ libgui.so@0x1b859] [@ libgui.so@0x1b91d] [@ libgui.so@0x1b92d] [@ libgui.so@0x1bb65] [@ libgui.so@0x1bba1] [@ lib…
Depends on: 756916
No longer depends on: 756916
bug 756916 has also STR.
Ok, I can now reproduce this on a Transformer running ICS. I get the same crash as Julian, which is presumably the same as the one in the report. Oddly, I can't reproduce it on my Galaxy Nexus. The Java stack trace for the relevant thread at the time of the crash looks like this: I/dalvikvm( 8509): "FinalizerDaemon" daemon prio=5 tid=7 NATIVE I/dalvikvm( 8509): | group="main" sCount=1 dsCount=0 obj=0x41077eb8 self=0x19739b8 I/dalvikvm( 8509): | sysTid=8518 nice=0 sched=0/0 cgrp=default handle=26459184 I/dalvikvm( 8509): | schedstat=( 185255000 166540000 551 ) utm=14 stm=4 core=1 I/dalvikvm( 8509): at android.graphics.SurfaceTexture.nativeRelease(Native Method) I/dalvikvm( 8509): at android.graphics.SurfaceTexture.release(SurfaceTexture.java:225) I/dalvikvm( 8509): at java.lang.reflect.Method.invokeNative(Native Method) I/dalvikvm( 8509): at java.lang.reflect.Method.invoke(Method.java:511) I/dalvikvm( 8509): at org.mozilla.gecko.gfx.SurfaceTextureLayer.finalize(SurfaceTextureLayer.java:139) I/dalvikvm( 8509): at java.lang.Daemons$FinalizerDaemon.doFinalize(Daemons.java:182) I/dalvikvm( 8509): at java.lang.Daemons$FinalizerDaemon.run(Daemons.java:168) I/dalvikvm( 8509): at java.lang.Thread.run(Thread.java:856) I/dalvikvm( 8509): | schedstat=( 23987000 5425000 647 ) utm=2 stm=0 core=1 I/dalvikvm( 8509): at java.lang.Object.wait(Native Method) I/dalvikvm( 8509): - waiting on <0x40a154f8> I/dalvikvm( 8509): at java.lang.Object.wait(Object.java:364) I/dalvikvm( 8509): at java.lang.Daemons$ReferenceQueueDaemon.run(Daemons.java:128) I/dalvikvm( 8509): at java.lang.Thread.run(Thread.java:856) According to that it looks like my patch should have fixed it. I'm looking into other solutions now.
Ok, with my patch I can no longer reproduce the SurfaceTexture crash. I now only get the PushLocalFrame/OutOfMemory error after the test runs for a longer amount of time. So the patch seems to fix this bug, but the STR in comment #34 also exposes a different bug. If Julian can confirm that it "fixes" it for him, we should get that patch in.
Blocks: 738198
Attachment #625204 - Attachment is obsolete: true
The attached patch fixes both the SurfaceTexture finalization issue (my first patch) and fixes the OOM issue which is also caused by the STR for this bug.
Attachment #625720 - Attachment is obsolete: true
Attachment #625720 - Flags: review?(jseward)
Attachment #625770 - Flags: review?(blassey.bugs) → review+
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #41) > Created attachment 625770 [details] [diff] [review] > Don't call methods on finalized SurfaceTexture, JNI housekeeping LGTM. Without the patch, Fennec dies for me within a few (10 ish) iterations of the test case in comment #19. With the patch, it was going strong after 230 iterations and I got bored watching it. Also I ran it for about 100 iterations on Valgrind and saw no related memory management errors, afaics. So, +1 from here.
https://hg.mozilla.org/mozilla-central/rev/d39453135698
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 15
Verified fixed in today's build, I haven't been able to crash Fennec anymore when Flash is enabled, thus far.
Status: RESOLVED → VERIFIED
(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #46) > Verified fixed in today's build, I haven't been able to crash Fennec anymore > when Flash is enabled, thus far. martijn, given the widespread outcome of this bug, can you also verify the duped bugs to check if they are fixed also?
I haven't checked the duped bugs, but some simple fuzzing didn't give any crashes anymore.
Comment on attachment 625770 [details] [diff] [review] Don't call methods on finalized SurfaceTexture, JNI housekeeping [Approval Request Comment] Fixes a commmon Flash crasher, low risk. Mobile only.
Attachment #625770 - Flags: approval-mozilla-aurora?
Attachment #625770 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/0f8d261df14b
Status: VERIFIED → REOPENED
status-firefox14: affected → ---
Resolution: FIXED → ---
Target Milestone: Firefox 15 → ---
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
status-firefox14: --- → fixed
Resolution: --- → FIXED
SV or QA, can we get this tested against beta 3? This would be a good bug to verify (and the duplicates too)
Unable to reproduce the issue using http://people.mozilla.org/~mwargers/tests/plugins/flash/flashembed_wrappedinlink_back_and_forth.html or or following the steps from Comment 5 on HTC Desire Z running Android 2.3.3 on Firefox 14.0b3 build 2, Aurora 2012-05-24 and Nightly 2012-05-24. I am also unable to reproduce on Firefox 14.0b3 build 2 the duplicated bugs: Bug 754118, Bug 755292, Bug 756916 and Bug 757424.
Status: RESOLVED → VERIFIED
Verified on beta 3.
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: