Status

()

defect
--
critical
VERIFIED FIXED
8 years ago
7 years ago

People

(Reporter: nhirata, Assigned: snorp)

Tracking

({crash, reproducible, topcrash})

Trunk
ARM
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

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

Details

(Whiteboard: [native-crash], crash signature)

Attachments

(3 attachments, 2 obsolete attachments)

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.
Duplicate of this bug: 754118
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.
Duplicate of this bug: 755292
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
Duplicate of this bug: 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: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 15
Duplicate of this bug: 757424
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
Resolution: FIXED → ---
Target Milestone: Firefox 15 → ---
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
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.
You need to log in before you can comment on or make changes to this bug.