Last Comment Bug 750217 - Android crash in nsNPAPIPluginInstance::TimerWithID
: Android crash in nsNPAPIPluginInstance::TimerWithID
Status: RESOLVED FIXED
[native-crash]
: crash, reproducible, topcrash
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: Trunk
: ARM Android
: -- critical (vote)
: mozilla18
Assigned To: James Willcox (:snorp) (jwillcox@mozilla.com)
:
Mentors:
: 732059 759109 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-30 05:07 PDT by Scoobidiver (away)
Modified: 2013-04-13 07:43 PDT (History)
9 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
+
fixed
fixed
fixed
-
+


Attachments
Don't schedule plugin timers if the plugin isn't running (1.06 KB, patch)
2012-09-10 09:59 PDT, James Willcox (:snorp) (jwillcox@mozilla.com)
jaas: review+
bajaj.bhavana: approval‑mozilla‑aurora+
bajaj.bhavana: approval‑mozilla‑beta+
Details | Diff | Splinter Review

Description Scoobidiver (away) 2012-04-30 05:07:17 PDT
Signature 	nsNPAPIPluginInstance::TimerWithID More Reports Search
UUID	a49c0aac-2407-4a85-addb-fe9be2120430
Date Processed	2012-04-30 11:23:42
Uptime	246
Install Age	4.1 minutes since version was first installed.
Install Time	2012-04-30 11:19:27
Product	FennecAndroid
Version	14.0a2
Build ID	20120429042006
Release Channel	aurora
OS	Linux
OS Version	0.0.0 Linux 2.6.35.11-perf #1 SMP PREEMPT Tue Feb 14 18:02:08 KST 2012 armv7l
Build Architecture	arm
Build Architecture Info	
Crash Reason	SIGSEGV
Crash Address	0x0
App Notes 	
EGL? EGL+ AdapterVendorID: qcom, AdapterDeviceID: LG-MS840.
AdapterDescription: 'Android, Model: 'LG-MS840', Product: 'cayman_mpcs_us', Manufacturer: 'LGE', Hardware: 'qcom''.
GL Context? GL Context+ GL Layers? GL Layers+ 
LGE LG-MS840
lge/cayman_mpcs_us/cayman:2.3.6/GRK39F/MS840ZV8.47A73A3A:user/release-keys
EMCheckCompatibility	True

Frame 	Module 	Signature 	Source
0 	libxul.so 	nsNPAPIPluginInstance::TimerWithID 	nsTArray.h:224
1 	libxul.so 	PluginTimerCallback 	dom/plugins/base/nsNPAPIPluginInstance.cpp:1215
2 	libxul.so 	nsTimerImpl::Fire 	xpcom/threads/nsTimerImpl.cpp:508
3 	libxul.so 	nsTimerEvent::Run 	xpcom/threads/nsTimerImpl.cpp:591
4 	libxul.so 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:656
5 	libxul.so 	NS_ProcessNextEvent_P 	obj-firefox/xpcom/build/nsThreadUtils.cpp:245
6 	libxul.so 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:110
7 	libxul.so 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:208
8 	libxul.so 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:201
9 	libxul.so 	nsBaseAppShell::Run 	widget/xpwidgets/nsBaseAppShell.cpp:189
10 	libxul.so 	nsAppStartup::Run 	toolkit/components/startup/nsAppStartup.cpp:295
11 	libxul.so 	XREMain::XRE_mainRun 	toolkit/xre/nsAppRunner.cpp:3780
12 	libxul.so 	XREMain::XRE_main 	toolkit/xre/nsAppRunner.cpp:3857
13 	libxul.so 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3933
14 	libxul.so 	GeckoStart 	toolkit/xre/nsAndroidStartup.cpp:109
...

More reports at:
https://crash-stats.mozilla.com/report/list?signature=nsNPAPIPluginInstance%3A%3ATimerWithID
Comment 1 Scoobidiver (away) 2012-06-10 01:15:59 PDT
It's #15 top crasher in 14.0b6.
Comment 2 Scoobidiver (away) 2012-06-26 04:10:26 PDT
Now that some top crashers are fixed, it's #11 top crasher in 14.0b8.
Comment 4 Scoobidiver (away) 2012-07-04 09:44:18 PDT
Cristian, what are the STR?
Comment 5 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2012-07-05 12:47:58 PDT
This looks a lot to me like we're tearing down the plugin instance from within the timer (it could also be calling a timer on a dead instance, but I'd expect that to normally crash earlier in the method) . The comment "Make sure we still have an instance and the timer is still alive" is scary. We should almost certainly be protecting against plugin teardown using a PluginDestructionGuard at the top of PluginTimerCallback. Do we have a good way of verifying hunches like that?
Comment 6 Cristian Nicolae (:xti) 2012-07-27 01:14:12 PDT
(In reply to Scoobidiver from comment #4)
> Cristian, what are the STR?

I was able to reproduce this crash always with the following STR, but I cannot anymore now on latest Nightly, Aurora or Beta builds.

STR:
1. Open Fennec
2. Go to http://www.adobe.com/software/flash/about/
3. Tap to activate flash plugin
4. Wait

Expected result:
No crash should occur.

Actual result:
This crash will occur.


On the latest builds, instead of this crash, I will get some libflashplayer.so crashes.

--
Device: Galaxy Nexus
OS: Android 4.0.4
Comment 7 Scoobidiver (away) 2012-08-24 02:52:06 PDT
It's now #3 top crasher in 15.0b6.
Comment 8 Cristian Nicolae (:xti) 2012-08-28 05:23:18 PDT
I am always able to reproduce this crash on the latest Nightly by following these STR:

1. Go to http://goo.gl/j3xAP (http://www.digisport.ro/Sport/FOTBAL/Competitii/Liga+1/fc+vaslui+steaua+live+text+video)
2. Tap on any video to enable the flash plug in
3. Tap on the Reader Mode icon from URL Bar

Expected result:
The page should be displayed in Reader Mode correctly.

Actual result:
https://crash-stats.mozilla.com/report/index/bp-ced8caed-1b5d-458c-83f3-82aed2120828

--
Firefox 18.0a1 (2012-08-28)
Device: Galaxy Note
OS: Android 4.0.4
Comment 9 Alex Keybl [:akeybl] 2012-08-28 10:11:30 PDT
Snorp - do you have the time to look into this? If not, please hand this off to blassey to reassign.
Comment 10 James Willcox (:snorp) (jwillcox@mozilla.com) 2012-08-28 10:29:35 PDT
(In reply to Alex Keybl [:akeybl] from comment #9)
> Snorp - do you have the time to look into this? If not, please hand this off
> to blassey to reassign.

I can look at it.
Comment 11 James Willcox (:snorp) (jwillcox@mozilla.com) 2012-09-10 09:59:02 PDT
Created attachment 659754 [details] [diff] [review]
Don't schedule plugin timers if the plugin isn't running
Comment 12 James Willcox (:snorp) (jwillcox@mozilla.com) 2012-09-10 10:00:30 PDT
*** Bug 732059 has been marked as a duplicate of this bug. ***
Comment 13 James Willcox (:snorp) (jwillcox@mozilla.com) 2012-09-10 10:01:03 PDT
*** Bug 759109 has been marked as a duplicate of this bug. ***
Comment 14 Josh Aas 2012-09-10 16:17:51 PDT
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #11)
> Created attachment 659754 [details] [diff] [review]
> Don't schedule plugin timers if the plugin isn't running

How did you confirm that this patch works? Were you able to reproduce locally, and this patch fixed the problem, or is this a guess?
Comment 15 James Willcox (:snorp) (jwillcox@mozilla.com) 2012-09-10 22:19:08 PDT
(In reply to Josh Aas (Mozilla Corporation) from comment #14)
> (In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #11)
> > Created attachment 659754 [details] [diff] [review]
> > Don't schedule plugin timers if the plugin isn't running
> 
> How did you confirm that this patch works? Were you able to reproduce
> locally, and this patch fixed the problem, or is this a guess?

Yes, I was able to reproduce it locally. This patch fixed it.
Comment 16 James Willcox (:snorp) (jwillcox@mozilla.com) 2012-09-11 07:29:30 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/ef085eb72cd8
Comment 17 Ryan VanderMeulen [:RyanVM] 2012-09-11 18:46:22 PDT
https://hg.mozilla.org/mozilla-central/rev/ef085eb72cd8
Comment 18 Alex Keybl [:akeybl] 2012-09-12 09:54:37 PDT
Please nominate for Aurora/Beta approval this week, once comfortable with the landed change.
Comment 19 James Willcox (:snorp) (jwillcox@mozilla.com) 2012-09-13 11:35:48 PDT
No crashes since 9/9 build it looks like, which doesn't include my fix. Still, seems to be good now.
Comment 20 James Willcox (:snorp) (jwillcox@mozilla.com) 2012-09-13 11:36:24 PDT
Comment on attachment 659754 [details] [diff] [review]
Don't schedule plugin timers if the plugin isn't running

[Approval Request Comment]
Fixes prominent plugin crash, low-risk
Comment 21 James Willcox (:snorp) (jwillcox@mozilla.com) 2012-09-18 06:42:12 PDT
https://hg.mozilla.org/releases/mozilla-aurora/rev/293fddc7db0c
Comment 22 James Willcox (:snorp) (jwillcox@mozilla.com) 2012-09-18 06:47:49 PDT
https://hg.mozilla.org/releases/mozilla-beta/rev/705cb96776a1
Comment 23 Scoobidiver (away) 2012-09-20 23:09:51 PDT
It's not fully fixed because there are one crash in 18.0a1/20120919 and another in 17.0a2/20120920.
Comment 24 Steve Chan 2013-04-13 06:44:57 PDT
Do the same
> (In reply to Scoobidiver from comment #4)
> > Cristian, what are the STR?
> 
> I was able to reproduce this crash always with the following STR, but I
> cannot anymore now on latest Nightly, Aurora or Beta builds.
> 
> STR:
> 1. Open Fennec
> 2. Go to http://www.adobe.com/software/flash/about/
> 3. Tap to activate flash plugin
> 4. Wait
> 
> Expected result:
> No crash should occur.
> 
> Actual result:
> This crash will occur.
> 
> 
> On the latest builds, instead of this crash, I will get some
> libflashplayer.so crashes.
> 
> --
> Device: Galaxy Nexus
> OS: Android 4.0.4

But there're still crash page: http://truyenyy.com/doc-truyen/dinh-cap-luu-manh/chuong-957/ in 19.02 version.
Comment 25 Scoobidiver (away) 2013-04-13 07:43:13 PDT
Steve, this bug is fixed. In addition, the release version is 20.0.1.

If you experience crashes on that site, type about:crashes, click the crash report and scroll down to Related Bugs to see where there's a related bug.

Note You need to log in before you can comment on or make changes to this bug.