768000 - Android Flash crash in AudioRunnable::Run

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect)

Description

[Scoobidiver (away)]

It's #31 top crasher in 14.0b8.

Signature 	libflashplayer.so@0x533b79 More Reports Search
UUID	45af7a91-25cb-4434-8583-621782120623
Date Processed	2012-06-23 04:42:32
Uptime	349
Last Crash	2.7 weeks before submission
Install Age	5.2 hours since version was first installed.
Install Time	2012-06-22 23:30:17
Product	FennecAndroid
Version	14.0
Build ID	20120621141442
Release Channel	beta
OS	Linux
OS Version	0.0.0 Linux 3.0.32-ck1-cfs-g1962093 #6 PREEMPT Wed May 23 12:44:28 CDT 2012 armv7l
Build Architecture	arm
Build Architecture Info	
Crash Reason	SIGSEGV
Crash Address	0x5d43b9b0
App Notes 	
AdapterVendorID: herring, AdapterDeviceID: Nexus S 4G.
AdapterDescription: 'Model: 'Nexus S 4G', Product: 'sojus', Manufacturer: 'Samsung', Hardware: 'herring''.
Samsung Nexus S 4G
google/sojus/crespo4g:4.0.4/IMM76D/299849:user/release-keys
EMCheckCompatibility	True
Adapter Vendor ID	herring
Adapter Device ID	Nexus S 4G

Frame 	Module 	Signature 	Source
0 		@0x5d43b9b0 	
1 	dalvik-heap (deleted) 	dalvik-heap @0xcf3abe 	
2 	dalvik-heap (deleted) 	dalvik-heap @0xcf3abe 	
3 	libflashplayer.so 	libflashplayer.so@0x533b79 	
4 	libxul.so 	AudioRunnable::Run 	dom/plugins/base/android/ANPAudio.cpp:182
5 	libxul.so 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:656
6 	libxul.so 	NS_ProcessNextEvent_P 	obj-firefox/xpcom/build/nsThreadUtils.cpp:245
7 	libxul.so 	nsThread::ThreadFunc 	xpcom/threads/nsThread.cpp:289
8 	libnspr4.so 	_pt_root 	nsprpub/pr/src/pthreads/ptthread.c:187
9 	libc.so 	libc.so@0x12ca6 	
10 	libc.so 	libc.so@0x127d6

More reports at:
https://crash-stats.mozilla.com/report/list?signature=libflashplayer.so%400x533b79

Comment 1

[Scoobidiver (away)]

Is there a way to fix it by a patch similar to the one of bug 750217?

Comment 2

[Scoobidiver (away)]

With combined signatures, it's #7 top crasher in 17.0, #2 in 18.0b4 and #10 in 19.0a2.

More reports at:
https://crash-stats.mozilla.com/query/query?product=FennecAndroid&query_search=signature&query_type=contains&query=libflashplayer.so%400x53&do_query=1

Comment 3

[Alex Keybl [:akeybl]]

Snorp - any ideas as to what's going on here from inspection of the stack?

KaiRo - can you pull more device/URL info so that QA can test? Please add qawanted/steps-wanted once you find something actionable.

Thanks!

Comment 4

[Marcia Knous [:marcia]]

Some of the URLs are porn, I can send those via email to those interested - these are URLs culled from across all the signatures:

Total Count 	URL
1 	https://apps.facebook.com/avengersalliance/?fb_source=bookmark_apps&ref=bookmark
1 	http://www.worldstarcandy.com/candy/53333
1 	http://www.dromadaire.com/w/descr/296_Anniversaire/6594_Happy-Birthday--lettres-
1 	http://abc.go.com/watch/last-resort/SH55199666/VD55251792/big-chicken-dinner
1 	http://pet.qq.com/apps/qqsh/?ADTAG=ied.web.gw
1 	https://apps.facebook.com/wly_online/
1 	http://opentuition.com/acca/p2/consolidations-simple-groups-introduction-part-a/
1 	http://www.marcophono.com/flatrate_14_b.html

Comment 5

[Robert Kaiser]

I saw at least 30-40 different devices in those crashes when looking through just today's reports, the largest crash count seem to be on Motorola DROID RAZR, Asus Nexus 7, Samsung GT-P3100, Sony Ericsson MT11i, but there are many, many more, see e.g. https://crash-analysis.mozilla.com/rkaiser/2012-12-18/2012-12-18.fennecandroid.beta.17.0.devices.html

Comment 6

[Robert Kaiser]

snorp, is there anything we can do about those?

Comment 7

[Alex Keybl [:akeybl]]

Kevin - can you give reproducing this a go? Please contact Marcia for more URLs if you're comfortable with testing the Flash videos she mentioned.

Comment 8

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

Attachment: Don't race when destroying plugin audio tracks on Android

Comment 9

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

I haven't reproduced this one, but it looks like we are probably calling mTrack->proc() after deleteTrack is called, which Flash could be unhappy about.

It might also be possible that the plugin has been destroyed without deleteTrack being called. This didn't happen in my testing, but it will be my next plan of attack if the attached bug does not fix things.

Comment 10

[Scoobidiver (away)]

Gingerbread and Honeycomb are also affected.

More reports at:
https://crash-stats.mozilla.com/report/list?signature=NP_Shutdown+|+AudioRunnable%3A%3ARun
https://crash-stats.mozilla.com/report/list?signature=NP_Shutdown+|+AudioRunnable%3A%3ARun%28%29

Comment 11

[Robert Kaiser]

Scoobidiver, let's leave the NP_Shutdown out of summaries as it's merely an artifact, it's not really the NP_Shutdown function that is involved. It's better to just point out in the summary that it's Android Flash.

Comment 12

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/a5a717b40112

Comment 13

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

Attachment: Fix up the mutex handling in the prior patch

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/a5a717b40112

Comment 15

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/f28ae1d9b685

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/f28ae1d9b685

Comment 17

[Robert Kaiser]

So far, no crashes after the build of the 27th yet - but then, Nightly has somewhat low user numbers. Uplifting to Beta would show us better if it really worked (Aurora only has a little more users than Nightly, but might help somewhat as well).

Comment 18

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

Comment on attachment 705493 [details] [diff] [review]
Don't race when destroying plugin audio tracks on Android

[Approval Request Comment]
Fixes a top crash, low risk. Need to get on Aurora/Beta to get more exosure for this speculative fix.

Comment 19

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

https://hg.mozilla.org/releases/mozilla-aurora/rev/f47d6dfbcee0
https://hg.mozilla.org/releases/mozilla-aurora/rev/542331c05752

https://hg.mozilla.org/releases/mozilla-beta/rev/963e7b1db85f
https://hg.mozilla.org/releases/mozilla-beta/rev/1aadb8b6552b

Comment 20

[Kevin Brosnan [Ex-Mozilla]]

This looks to be fixed via crash stats.

Comment 21

[Scoobidiver (away)]

It's not fixed. See bp-ba716389-99ae-4d3e-b80e-116652130131.

Comment 22

[Robert Kaiser]

(In reply to Scoobidiver from comment #21)
> It's not fixed. See bp-ba716389-99ae-4d3e-b80e-116652130131.

Has the volume changed? That is, has it fixed at least a significant part of those crashes?

Comment 23

[Scoobidiver (away)]

(In reply to Robert Kaiser (:[e-mail]) from comment #22)
> Has the volume changed? 
It usually skips several Nightly builds so we can't conclude before several days. We will have also a better estimation with Aurora and Beta.

Comment 24

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

Well that sucks. I think it's likely that we are doing everything right, but Flash just crashes on its own for some reason when we ask it for audio data. I'll look into it some more.

Comment 25

[Scoobidiver (away)]

(In reply to Robert Kaiser (:[e-mail]) from comment #22)
> Has the volume changed? That is, has it fixed at least a significant part of
> those crashes?
With combined signatures, it was #2 top crasher in 19.0b3 and is #5 in 19.0b4. The difference in ranking is explained by two new top crashers appeared in 19.0b4 so it's not even partially fixed.

Comment 26

[Robert Kaiser]

Actually, from the crashes per million ADI numbers in my explosiveness reports, it looks like it might have slightly declined in b4, but not by a real lot.

Comment 27

[Scoobidiver (away)]

The patch hasn't fixed the issue.

Comment 28

[Robert Kaiser]

I cannot post URLs on this one,  as all with multiple hits are adult websites, judging from the URLs.

Comment 29

[Lukas Blakk [:lsblakk] use ?needinfo]

Will want to keep an eye on this when 20 gets on Beta.

Comment 30

[Lukas Blakk [:lsblakk] use ?needinfo]

Current volume on 20 is quite low, untracking.

Comment 31

[Scoobidiver (away)]

(In reply to Lukas Blakk [:lsblakk] from comment #30)
> Current volume on 20 is quite low, untracking.
#10 top crasher (combined signatures over less than one day) still qualifies it for the topcrash keyword.

Comment 32

[Robert Kaiser]

Sorry, Scoobidiver, but nothing measured over less than a day qualifies for the topcrash keyword.

Comment 33

[Scoobidiver (away)]

(In reply to Robert Kaiser (:[e-mail]) from comment #32)
> Sorry, Scoobidiver, but nothing measured over less than a day qualifies for
> the topcrash keyword.
It has been untracked based on less-than-one-day crash stats. See comment 30.

Comment 34

[Lukas Blakk [:lsblakk] use ?needinfo]

OK we'll check back in a few days and leave this nominated for now, if the volume is different than previous releases we'll track.

Comment 35

[Scoobidiver (away)]

Two days and half after the release of 20.0b1, it's #6 top crasher with combined signatures. It has been a top crasher since 17.0 but tracked only for 19.0.

Comment 36

[Robert Kaiser]

Yes, we should not track because it's not new and it's not getting worse.

Comment 37

[Scoobidiver (away)]

(In reply to Robert Kaiser (:[e-mail]) from comment #36)
> Yes, we should not track because it's not new and it's not getting worse.
It would be the first Fennec top crasher tracked only for one version. See bug 752828, bug 812881, bug 823236, bug 778935, bug 827254, bug 791958 for instance.

Comment 38

[Robert Kaiser]

(In reply to Scoobidiver from comment #37)
> It would be the first Fennec top crasher tracked only for one version.

I freely admit that 1) we make mistakes, 2) the rules are different for different bugs. This here is something that *is not our fault but a Flash bug* from all we know, and we tried workaround patches that didn't help. There is no gain in further tracking, in fact even this discussion with you about it is draining resources that could be better used elsewhere.

Comment 39

[Scoobidiver (away)]

If it's a Flash crash that can not be worked around in the Firefox code, I am fine to untrack it for 20.0 but that's not the given reason in comment 30.

Comment 40

[Lukas Blakk [:lsblakk] use ?needinfo]

Agree with comment 38, no point in further tracking here.

Comment 41

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

filter on [mass-p5]

Comment 42

[u597032]

Flash is finally going, Bug 1381916.

Comment 43

[Chris Peterson [:cpeterson]]

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

Comment 44

[Chris Peterson [:cpeterson]]

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