Closed Bug 827254 Opened 11 years ago Closed 11 years ago

crash in nsNPAPIPluginInstance::SetWakeLock on ICS and above

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
ARM
Android
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(firefox17 wontfix, firefox18 wontfix, firefox19+ wontfix, firefox20+ fixed, firefox21 fixed, firefox22 fixed, fennec19+)

Status:
RESOLVED FIXED
Milestone:
mozilla22
Tracking Flags:
Tracking Status
firefox17 --- wontfix
firefox18 --- wontfix
firefox19 + wontfix
firefox20 + fixed
firefox21 --- fixed
firefox22 --- fixed
fennec 19+ ---

People

(Reporter: scoobidiver, Assigned: snorp)

References

Details

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

Crash Data

Attachments

(1 file)

Guard against garbage plugin instance in ANPSystem::setPowerState
1.10 KB, patch
blassey
: review+
lsblakk
: approval-mozilla-aurora+
lsblakk
: approval-mozilla-beta+
Details | Diff | Splinter Review 
I don't know whether it's a plugin or Flash crash.
It's #119 top crasher in 17.0, #80 in 18.0b7, #8 in 19.0a2 and #39 in 20.0a1.

Signature 	nsNPAPIPluginInstance::SetWakeLock(bool) More Reports Search
UUID	cb4bf457-36b1-4c4b-90b1-367892130103
Date Processed	2013-01-03 16:25:33
Uptime	656
Last Crash	11.0 minutes before submission
Install Age	1.1 days since version was first installed.
Install Time	2013-01-02 14:25:56
Product	FennecAndroid
Version	20.0a1
Build ID	20130102030907
Release Channel	nightly
OS	Android
OS Version	0.0.0 Linux 3.0.31-gd5a18e0 #1 SMP PREEMPT Fri Nov 2 11:02:59 PDT 2012 armv7l google/yakju/maguro:4.2.1/JOP40D/533553:user/release-keys
Build Architecture	arm
Build Architecture Info	
Crash Reason	SIGSEGV
Crash Address	0x70004f
App Notes 	
AdapterDescription: 'Imagination Technologies -- PowerVR SGX 540 -- OpenGL ES 2.0 build 1.8@905891 -- Model: Galaxy Nexus, Product: yakju, Manufacturer: samsung, Hardware: tuna'
EGL? EGL+ GL Context? GL Context+ GL Layers? GL Layers+ Stagefright? Stagefright+ 
samsung Galaxy Nexus
google/yakju/maguro:4.2.1/JOP40D/533553:user/release-keys
Processor Notes 	/data/socorro/stackwalk/bin/exploitable: ERROR: unable to analyze dump
EMCheckCompatibility	True
Adapter Vendor ID	Imagination Technologies
Adapter Device ID	PowerVR SGX 540
Device	samsung Galaxy Nexus
Android API Version	17 (REL)
Android CPU ABI	armeabi-v7a

Frame 	Module 	Signature 	Source
0 	libxul.so 	nsNPAPIPluginInstance::SetWakeLock 	nsNPAPIPluginInstance.cpp:922
1 	libxul.so 	anp_system_setPowerState 	ANPSystem.cpp:71
2 	libflashplayer.so 	libflashplayer.so@0x52de21 	
3 	libflashplayer.so 	libflashplayer.so@0x759e5e 	
...
28 	libflashplayer.so 	libflashplayer.so@0x54e14b 	
29 	libnspr4.so 	PR_Unlock 	ptsynch.c:208
30 	libxul.so 	nsAppShell::NotifyNativeEvent 	Mutex.h:83
31 	libxul.so 	nsAppShell::PostEvent 	nsAppShell.cpp:733 

More reports at:
https://crash-stats.mozilla.com/report/list?signature=nsNPAPIPluginInstance%3A%3ASetWakeLock
https://crash-stats.mozilla.com/report/list?signature=nsNPAPIPluginInstance%3A%3ASetWakeLock%28bool%29
It's #11 top crasher in 19.0b1.
tracking-fennec: --- → ?
status-firefox21: --- → affected
tracking-firefox19: --- → ?
Keywords: topcrash
snorp, this looks like it's related to interaction with Flash, can you take a look?

This is significantly higher in 19 than versions before.
Assignee: nobody → snorp
tracking-fennec: ? → 19+
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #2)
> snorp, this looks like it's related to interaction with Flash, can you take
> a look?
> 
> This is significantly higher in 19 than versions before.

Can we get URLs and device correlations to help in QA's investigation?
Flags: needinfo?(kairo)
Keywords: qawanted, steps-wanted
URLs from both signatures for the recent week:
1 	http://www.itmedia.co.jp/pcuser/articles/1301/18/news118.html
1 	http://search.naver.com/search.naver?where=nexearch&query=r3+%EC%BC%80%EC%9D%B4%EC%8A%A4&sm=top_sug.pre&fbm=1&acr=2&acq=r3&qdt=0&ie=utf8
1 	http://www.tabnak.ir/
1 	http://webtv.hurriyet.com.tr/4/44065/22376635/1/guiza-serbest-vurustan-muhtesem-bir-gol-atti.aspx
1 	http://www.anime-stream24.com/2012/10/naruto-shippuuden-284-ger-sub.html
1 	http://www.sat-digest.com/
1 	http://forums.androidcentral.com/t-galaxy-s-ii/160421-help-android-market-app-go
1 	http://dailynews.yahoo.co.jp/fc/domestic/entrance_exam/?1358594114
1 	http://gamingbolt.com/10-outrageously-difficult-games-from-recent-years?cfield=m
1 	http://www.facebook.com/connect/uiserver.php?app_id=6953377468&method=permission
1 	http://www.yahoo.co.jp/
1 	http://d.hatena.ne.jp/nyama/edit
1 	http://www.migente.com/home/index.html

Device stats from 19.0 beta in yesterday's data:

nsNPAPIPluginInstance::SetWakeLock(bool) 	33
Asus Nexus 7 	12
Samsung GT-P5100 	2
Samsung GT-I9300 	2
ASUS Transformer Pad TF300T 	2
Samsung GT-P6200 	1
Sony SGPT12 	1
Unknown TAB9008GBBK 	1
Unknown DLHD 	1
Samsung GT-I9100 	1
Samsung SCH-I535 	1
NEC N-07D 	1
Bq bq Edison 	1
Acer A511 	1
ASUS Transformer Pad TF300TG 	1
HTC Desire C 	1
HTC One S 	1
Motorola MZ609 	1
HTC One X 	1
Rockchip Android 	1

Device stats from 18.0 release in yesterday's data:

nsNPAPIPluginInstance::SetWakeLock 	22
Asus Nexus 7 	4
Samsung GT-I9300 	3
Acer A500 	2
Samsung GT-N8013 	1
Samsung Nexus 10 	1
Sony ST25i 	1
Unknown CT704 	1
Samsung GT-N8010 	1
Samsung SGH-I957M 	1
Rockchip PMP5880D 	1
HTC One X 	1
HTC One S 	1
HTC Sensation XL with Beats Audio X315e 	1
MID Crystal 	1
ASUS Transformer Pad TF300T 	1
Samsung GT-N7100 	1
Flags: needinfo?(kairo)
given the prevalence of the nexus 7, I wonder if this is related to having old flash versions installed. Do we have the flash version info in the crash reports now?
(In reply to Brad Lassey [:blassey] from comment #5)
> given the prevalence of the nexus 7, I wonder if this is related to having
> old flash versions installed. Do we have the flash version info in the crash
> reports now?

No, I haven't yet seen anyone who could give us a list of "debug ID" <-> "Flash version" mappings. If we had that, I think the Socorro team could make a version display work.
We fixed plugin versions in bug 818664 for firefox20. So assuming the plugin version is in the plugin tag, it's in the crash reports now. See e.g. one of mine: https://crash-stats.mozilla.com/report/index/bp-728b3a0e-0d4d-48ed-a1d8-7608d2130116 which displays the plugin version.
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #7)
> We fixed plugin versions in bug 818664 for firefox20.

I didn't realize that, but I think it just might not help here, as I can't see anything like a plugin version even in the few crashes here that happen on Nightly. Almost all of those crashes are on 19 beta for Android - given that plugins run in-processs on Android, I'm not even sure if bug 818664 applies here at all as that seems to be in IPC code which AFAIK plugins aren't using here. :(
Oh yeah, if you're not using plugin processes that fix isn't relevant to android. We could possibly do some in-process crash annotation with plugin versions, though.
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #9)
> Oh yeah, if you're not using plugin processes that fix isn't relevant to
> android. We could possibly do some in-process crash annotation with plugin
> versions, though.

That would surely be nice for Android.
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #9)
> Oh yeah, if you're not using plugin processes that fix isn't relevant to
> android. We could possibly do some in-process crash annotation with plugin
> versions, though.

can you file a bug for that?
I loaded all the URLs provided by the two signatures that crash stats provided. No leads were found. Manually tested a few URLs by visiting several pages on that site.
Keywords: qawanted
I'll let you file the bug: you should verify that we actually know the plugin version on Android (we don't on Linux).
ni? for comment 13
status-firefox19: affected → wontfix
tracking-firefox20: --- → +
Flags: needinfo?(blassey.bugs)
filed bug 839456 to annotate crash reports
Flags: needinfo?(blassey.bugs)
Bug 839456 was fixed one week ago - what is the next step here?
I think this bug is probably similar to 800838 -- plugin is calling into the browser after it's been destroyed. It should be possible to use a similar workaround.
I know Brad *loves* to approve stuff like this
Attachment #719968 - Flags: review?(blassey.bugs)
Attachment #719968 - Flags: review?(blassey.bugs) → review+
Comment on attachment 719968 [details] [diff] [review]
Guard against garbage plugin instance in ANPSystem::setPowerState

[Approval Request Comment]
Low-risk speculative fix
Attachment #719968 - Flags: approval-mozilla-beta?
Attachment #719968 - Flags: approval-mozilla-aurora?
Comment on attachment 719968 [details] [diff] [review]
Guard against garbage plugin instance in ANPSystem::setPowerState

Since we don't have steps, approving this speculative fix for beta in order to get more user crash data to help us know if we're on the right track here.  This will need to be uplifted asap once the fix is on central successfully.
Attachment #719968 - Flags: approval-mozilla-beta?
Attachment #719968 - Flags: approval-mozilla-beta+
Attachment #719968 - Flags: approval-mozilla-aurora?
Attachment #719968 - Flags: approval-mozilla-aurora+
https://hg.mozilla.org/mozilla-central/rev/f72a3e510a65
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
Product: Core → Core Graveyard

Removing steps-wanted keyword because this bug has been resolved.

Keywords: steps-wanted
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: