738198 - crash in nsPluginInstanceOwner::~nsPluginInstanceOwner @ nsPluginInstanceOwner::RemovePluginView

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect)

Description

[Scoobidiver (away)]

It first appeared in 14.0a1/20120320. The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=58a2cd0203ee&tochange=ee554888d071
It's likely a regression from bug 737120.

Signature 	dvmAsmInstructionStart More Reports Search
UUID	705c59fc-e6ab-4b9c-b51f-815df2120322
Date Processed	2012-03-22 05:51:41
Uptime	760
Last Crash	1.1 days before submission
Install Age	12.7 minutes since version was first installed.
Install Time	2012-03-22 05:40:04
Product	FennecAndroid
Version	14.0a1
Build ID	20120321031151
Release Channel	nightly
OS	Linux
OS Version	0.0.0 Linux 2.6.32.9-perf #1 PREEMPT Wed Oct 19 09:31:26 2011 armv7l
Build Architecture	arm
Build Architecture Info	
Crash Reason	SIGSEGV
Crash Address	0x1c
App Notes 	
EGL? EGL+ AdapterVendorID: semc, AdapterDeviceID: MK16a.
AdapterDescription: 'Android, Model: 'MK16a', Product: 'MK16a_1250-3934', Manufacturer: 'Sony Ericsson', Hardware: 'semc''.
GL Context? GL Context+ GL Layers? GL Layers+ 
Sony Ericsson MK16a
SEMC/MK16a_1250-3934/MK16a:2.3.4/4.0.2.A.0.62/wf_v3w:user/release-keys
EMCheckCompatibility	True

Frame 	Module 	Signature [Expand] 	Source
0 	libdvm.so 	dvmAsmInstructionStart 	
1 	libdvm.so 	dvmMterpStd 	
2 	libdvm.so 	dvmInterpret 	
3 	libdvm.so 	dvmCallMethodV 	
4 	libdvm.so 	JNI_CreateJavaVM 	
5 	libxul.so 	_JNIEnv::CallStaticVoidMethod 	jni.h:778
6 	libxul.so 	nsPluginInstanceOwner::RemovePluginView 	dom/plugins/base/nsPluginInstanceOwner.cpp:1824
7 	libxul.so 	nsPluginInstanceOwner::~nsPluginInstanceOwner 	dom/plugins/base/nsPluginInstanceOwner.cpp:397
8 	libxul.so 	nsPluginInstanceOwner::~nsPluginInstanceOwner 	dom/plugins/base/nsPluginInstanceOwner.cpp:403
9 	libxul.so 	nsPluginInstanceOwner::Release 	dom/plugins/base/nsPluginInstanceOwner.cpp:405
10 	libxul.so 	nsEventListenerInfo::~nsEventListenerInfo 	nsAutoPtr.h:908
11 	libxul.so 	nsEventListenerInfo::~nsEventListenerInfo 	content/events/src/nsEventListenerService.h:58
12 	libxul.so 	nsEventListenerInfo::Release 	content/events/src/nsEventListenerService.cpp:68
13 	libxul.so 	XPCJSRuntime::GCCallback 	js/xpconnect/src/XPCJSRuntime.cpp:629
14 	libxul.so 	js::GCSlice 	js/src/jsgc.cpp:3745
15 	libxul.so 	js::IncrementalGC 	js/src/jsfriendapi.cpp:158
16 	libxul.so 	nsXPConnect::Collect 	js/xpconnect/src/nsXPConnect.cpp:425
17 	libxul.so 	nsXPConnect::GarbageCollect 	js/xpconnect/src/nsXPConnect.cpp:435
18 	libxul.so 	nsJSContext::GarbageCollectNow 	dom/base/nsJSEnvironment.cpp:2962
19 	libxul.so 	GCTimerFired 	dom/base/nsJSEnvironment.cpp:3123
20 	libxul.so 	nsTimerImpl::Fire 	xpcom/threads/nsTimerImpl.cpp:508
21 	libxul.so 	nsTimerEvent::Run 	xpcom/threads/nsTimerImpl.cpp:591
22 	libxul.so 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:657
23 	libxul.so 	NS_ProcessNextEvent_P 	obj-firefox/xpcom/build/nsThreadUtils.cpp:245
24 	libxul.so 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:110
25 	libxul.so 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:208
26 	libxul.so 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:201
27 	libxul.so 	nsBaseAppShell::Run 	widget/xpwidgets/nsBaseAppShell.cpp:189
28 	libxul.so 	nsAppStartup::Run 	toolkit/components/startup/nsAppStartup.cpp:295
29 	libxul.so 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3703
...

More reports at:
https://crash-stats.mozilla.com/report/list?signature=dvmAsmInstructionStart

Comment 2

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

this is the gecko thread, so we shouldn't need to call GetJNIForThread() [https://mxr.mozilla.org/mozilla-central/source/dom/plugins/base/nsPluginInstanceOwner.cpp#1814]. The reason I'm eyeing that suspiciously is that it then creates a java vm on the thread.

Comment 3

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

Attachment: patch

no idea if this will fix this crash, but moving the jni access out of dom/plugins and into the bridge is a bit of clean up I've been wanting to do anyway.

Comment 4

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

The 6th topcrash on the list for 14.0a1

Comment 5

[James Willcox (:snorp) ([e-mail]) (he/him)]

Comment on attachment 609621 [details] [diff] [review]
patch

This changes it to use AndroidBridge::GetJNIEnv() instead of GetJNIForThread(), but I think that's ok. It's not clear to me that this will fix the crash, though.

Comment 6

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

pushed https://hg.mozilla.org/integration/mozilla-inbound/rev/0edeaa911e1c

(In reply to James Willcox (:snorp) ([e-mail]) from comment #5)
> This changes it to use AndroidBridge::GetJNIEnv() instead of
> GetJNIForThread(), but I think that's ok. It's not clear to me that this
> will fix the crash, though.

I agree. I hope this fixes it, but if not its still a change that we want to make so we'll leave the patch in and reopen the bug.

Comment 7

[(no longer active)]

https://hg.mozilla.org/mozilla-central/rev/0edeaa911e1c

Comment 8

[Scoobidiver (away)]

There are still crashes after the patch landed.

Comment 9

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

#1 top crash right now

Comment 10

[Tony Chung [:tchung]]

I was able to reproduce the @dvmAsmSisterStart crash, which was duped to this one.

https://crash-stats.mozilla.com/report/index/bp-a578e360-fa2d-49f5-8c2f-4ddf32120424

STR
1) install 4-24-2012 nightly, HTC Sensation Android 2.3.4
2) visit full flash site: http://www.abc.net.au/iview
3) pan around, wait, crash.

Comment 11

[Martijn Wargers (dead)]

I got this crash once with this testcase:
http://people.mozilla.org/~mwargers/tests/plugins/flash/flashembed_wrappedinlink.html
Str:
- Tap on the plugin placeholder
- Tap on the result flash circle

But I often get the libflashplayer crash, that way too.

Tested on the Samsung Galaxy SII.

Comment 12

[Tony Chung [:tchung]]

Reproduced again, same STR as comment 10.

This time on a different device:  Nexus S, Android 2.3.3, 04-30-2012 latest-aurora branch build.

https://crash-stats.mozilla.com/report/index/a5487d10-8e9c-477e-b61b-e26342120430

Comment 13

[Adrian Tamas (:AdrianT)]

On a Motorola Droid Pro running Android 2.3.4 on Nightly/15.0a1 2012-05-01 on http://people.mozilla.org/~mwargers/tests/plugins/flash/flashembed_wrappedinlink.html i got 3 crashes which seem to be the same/related to this:
https://crash-stats.mozilla.com/report/index/bp-9cfd68c6-e5f0-434c-8081-4d10f2120502
https://crash-stats.mozilla.com/report/index/bp-7d6e709c-3f71-419a-bac8-de74e2120502
https://crash-stats.mozilla.com/report/index/bp-657dac4f-d747-4d21-b3b8-0526d2120502

Comment 15

[James Willcox (:snorp) ([e-mail]) (he/him)]

QA can we try to nail down some more reliable STR here. I can't repro on current inbound with the steps in #10 or #11.

Comment 16

[Gabriela [:gaby2300]]

I can't repro either with steps in #10 using a Galaxy S2, Android 2.3.4 and build 15.0a1 20120508

Comment 17

[Adrian Tamas (:AdrianT)]

Unable to reproduce the crash using the STR from Comment 10 and Comment 11 on Nightly 15.0a1 2012-05-08 using an HTC Desire (Android 2.2). Using the steps from Comment 11 i was able to reproduce the crash on Nightly 2012-05-01 - please see Comment 13 - which would suggest that this was fixed by the fix for another bug. 
On Aurora 14.0a2 2012-05-08 on http://people.mozilla.org/~mwargers/tests/plugins/flash/flashembed_wrappedinlink.html i get another crash - Bug 753276. This is specific to Aurora.

Comment 18

[Scoobidiver (away)]

Based on crash stats, it's fixed in 15.0a1/20120507. The working range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=94ce5f33a9ea&tochange=448f554f6acb
I guess it's either bug 752001 or bug 752014 that have fixed it (not backported to Aurora).

It's not fixed in Aurora.

Comment 19

[Martijn Wargers (dead)]

With the str, in comment 11, I now get bug 731288 (although it is a little bit more difficult to get the crash now, it seems).

Comment 20

[Scoobidiver (away)]

(In reply to Scoobidiver from comment #18)
> Based on crash stats, it's fixed in 15.0a1/20120507.
I talked too fast. There are still crashes in the trunk but at a lower volume:
https://crash-stats.mozilla.com/report/list?product=FennecAndroid&version=FennecAndroid%3A15.0a1&query_search=signature&query_type=contains&reason_type=contains&range_value=28&range_unit=days&do_query=1&signature=dvmAsmInstructionStart#graph
https://crash-stats.mozilla.com/report/list?product=FennecAndroid&version=FennecAndroid%3A15.0a1&query_search=signature&query_type=contains&reason_type=contains&range_value=28&range_unit=days&do_query=1&signature=dvmAsmSisterStart#graph

With combined signatures, it's #6 top crasher in 14.0a2 and #1 top unfixed crasher.

Comment 21

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

no crashes since 5/11

Comment 22

[Scoobidiver (away)]

There are still crashes in Aurora at a low level:
https://crash-stats.mozilla.com/report/list?product=FennecAndroid&version=FennecAndroid%3A14.0a2&query_search=signature&query_type=contains&reason_type=contains&range_value=28&range_unit=days&do_query=1&signature=dvmAsmInstructionStart#graph

Comment 23

[Scoobidiver (away)]

There are still crashes in the trunk: bp-c77a3e1b-59de-4b5c-a50a-cecae2120514

Comment 24

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

no longer a topcrash, renoming and suggesting that this no longer blocks

Comment 25

[Scoobidiver (away)]

(In reply to Brad Lassey [:blassey] from comment #21)
> no crashes since 5/11
It takes several days before a build becomes widespread.

(In reply to Brad Lassey [:blassey] from comment #24)
> no longer a topcrash, renoming and suggesting that this no longer blocks
With combined signatures, it's #2 top crasher in Aurora over the last day (#3 over the last 3 days, #1 over the last week)) from various users.

Comment 26

[Tony Chung [:tchung]]

I cant reproduce this on a 5-14 aurora build.  need to keep investigating

Comment 27

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

snorp, some patch that landed on trunk dropped the crash rate. Please figure out which patch that is and make sure it gets into the next beta build.

Comment 28

[Martijn Wargers (dead)]

Maybe that the fix for bug 731288 will fix this too?

Comment 29

[Tony Chung [:tchung]]

on 5-23-2012 nightly,

just talked with martijn , and he no longer sees this crash when running his testcase 
from comment 11.   I also dont see this crash from my url in comment 10.  

It's possibly that the libgui.so bug (bug 731288), may have fixed it.

Comment 30

[Scoobidiver (away)]

(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #28)
> Maybe that the fix for bug 731288 will fix this too?
No. There are still crashes in Aurora after the fix of bug 731288: bp-e76de306-4ba6-4a98-be24-47abd2120523.
Bug 741222 would help to know its real rank.

Comment 31

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

QAwanted still valid - Looks like we need some new repro steps if that crash signature still exists in yesterday's aurora build.

Comment 32

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

I was able to reproduce this:
1. set plugins to enable
2. go to http://people.mozilla.org/~mwargers/tests/plugins/flash/flashembed_wrappedinlink_back_and_forth_2s.html
3. click on the middle flash button

Expected: no crash
Actual : dvmAsmInstructionSet crash

I was able to consistently produce this on Aurora 2012-05-30 build on Galaxy S II  
What happens is the keyboard seems to appear when it redirects to coming to this flash page after trying to redirect to google.com and crashes.

Comment 33

[Johnathan Nightingale [:johnath]]

Re-triaging to strip out non-OMG-ON-FIRE release blockers - pushing this to .N+ but we'd still love to look at a safe patch.

Comment 34

[Scoobidiver (away)]

With combined signatures, it's at least #6 top crasher in 14.0b5.

Comment 35

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

I can't seem to reproduce this bug in the latest nightly (6/6/2012) using comment 32 and HTC Desire

Comment 36

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

(In reply to Scoobidiver from comment #34)
> With combined signatures, it's at least #6 top crasher in 14.0b5.

all these dvm* crash signatures are not good indicators that they are the same bug, which is why we've added dvm* to the skip list.

Comment 37

[Scoobidiver (away)]

(In reply to Brad Lassey [:blassey] from comment #36)
> all these dvm* crash signatures are not good indicators that they are the
> same bug, which is why we've added dvm* to the skip list.
The 3 crash signatures use the same pattern:
* dvmAsmInstructionStart | pattern
* dvmAsmSisterStart | pattern
* dvmHandleStackOverflow | dvmAsmSisterStart | pattern
For me, it's the same crash.
It's different from bug 758898.

Comment 38

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

nominating to remove from the .N+ list due to low crash volume.

Comment 39

[Scoobidiver (away)]

The latest crash happened in 14.0b5. There are no crashes in 14.0b6.