Closed Bug 768000 Opened 8 years ago Closed 2 years ago

Android Flash crash in AudioRunnable::Run

Categories

(Core :: Plug-ins, defect)

ARM
Android
defect
Not set

Tracking

()

RESOLVED INCOMPLETE
mozilla21
Tracking Status
firefox17 --- wontfix
firefox18 --- wontfix
firefox19 + wontfix
firefox20 - affected
firefox21 --- affected
firefox22 --- affected
firefox23 --- affected
firefox24 --- affected
firefox26 --- affected
fennec + ---

People

(Reporter: scoobidiver, Assigned: snorp)

References

Details

(Keywords: crash, steps-wanted, thirdparty, Whiteboard: [native-crash][unactionable])

Crash Data

Attachments

(2 files)

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
Crash Signature: [@ libflashplayer.so@0x533b79] → [@ libflashplayer.so@0x533b79] [@ libflashplayer.so@0x533da9]
Is there a way to fix it by a patch similar to the one of bug 750217?
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
tracking-fennec: --- → ?
Crash Signature: [@ libflashplayer.so@0x533b79] [@ libflashplayer.so@0x533da9] → [@ libflashplayer.so@0x533b79] [@ libflashplayer.so@0x533da9] [@ libflashplayer.so@0x533fe1] [@ libflashplayer.so@0x5340c9] [@ libflashplayer.so@0x534019] [@ libflashplayer.so@0x533b39] [@ libflashplayer.so@0x53e618] [@ libflashplayer.so@0x53eb84] …
Keywords: topcrash
Summary: crash in AudioRunnable::Run @ libflashplayer.so@0x53... → crash in AudioRunnable::Run @ libflashplayer.so@0x53... on ICS and above
Version: 14 Branch → Trunk
Crash Signature: [@ libflashplayer.so@0x533b79] [@ libflashplayer.so@0x533da9] [@ libflashplayer.so@0x533fe1] [@ libflashplayer.so@0x5340c9] [@ libflashplayer.so@0x534019] [@ libflashplayer.so@0x533b39] [@ libflashplayer.so@0x53e618] [@ libflashplayer.so@0x53eb84] … → [@ libflashplayer.so@0x533b79 ] [@ libflashplayer.so@0x533da9 ] [@ libflashplayer.so@0x533fe1 ] [@ libflashplayer.so@0x5340c9 ] [@ libflashplayer.so@0x534019 ] [@ libflashplayer.so@0x533b39 ] [@ libflashplayer.so@0x53e618 ] [@ libflashplayer.so@0x5…
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!
Assignee: nobody → snorp
Flags: needinfo?(kairo)
Keywords: needURLs
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
Flags: needinfo?(kairo)
Keywords: needURLs
tracking-fennec: ? → +
snorp, is there anything we can do about those?
Flags: needinfo?(snorp)
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.
QA Contact: kbrosnan
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.
Crash Signature: libflashplayer.so@0x53eb84 ] [@ libflashplayer.so@0x53e5ca ] [@ libflashplayer.so@0x53e658 ] [@ libflashplayer.so@0x53a76d ] → libflashplayer.so@0x53eb84 ] [@ libflashplayer.so@0x53e5ca ] [@ libflashplayer.so@0x53e658 ] [@ libflashplayer.so@0x53a76d ] [@ NP_Shutdown | AudioRunnable::Run]
Attachment #705493 - Flags: review?(blassey.bugs) → review+
Crash Signature: libflashplayer.so@0x53eb84 ] [@ libflashplayer.so@0x53e5ca ] [@ libflashplayer.so@0x53e658 ] [@ libflashplayer.so@0x53a76d ] [@ NP_Shutdown | AudioRunnable::Run] → libflashplayer.so@0x53eb84 ] [@ libflashplayer.so@0x53e5ca ] [@ libflashplayer.so@0x53e658 ] [@ libflashplayer.so@0x53a76d ] [@ NP_Shutdown | AudioRunnable::Run] [@ NP_Shutdown | NP_Shutdown | AudioRunnable::Run]
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
Crash Signature: libflashplayer.so@0x53eb84 ] [@ libflashplayer.so@0x53e5ca ] [@ libflashplayer.so@0x53e658 ] [@ libflashplayer.so@0x53a76d ] [@ NP_Shutdown | AudioRunnable::Run] [@ NP_Shutdown | NP_Shutdown | AudioRunnable::Run] → libflashplayer.so@0x53eb84 ] [@ libflashplayer.so@0x53e5ca ] [@ libflashplayer.so@0x53e658 ] [@ libflashplayer.so@0x53a76d ] [@ NP_Shutdown | AudioRunnable::Run] [@ @0x0 | NP_Shutdown | AudioRunnable::Run] [@ NP_Shutdown | NP_Shutdown | AudioRunnabl…
Summary: crash in AudioRunnable::Run @ libflashplayer.so@0x53... on ICS and above → crash in AudioRunnable::Run @ NP_Shutdown
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.
Summary: crash in AudioRunnable::Run @ NP_Shutdown → Android Flash crash in AudioRunnable::Run
https://hg.mozilla.org/mozilla-central/rev/a5a717b40112
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
Attachment #706034 - Flags: review?(blassey.bugs) → review+
Crash Signature: AudioRunnable::Run] [@ NP_Shutdown | AudioRunnable::Run()] [@ NP_Shutdown | NP_Shutdown | AudioRunnable::Run()] → AudioRunnable::Run] [@ NP_Shutdown | AudioRunnable::Run()] [@ @0x0 | NP_Shutdown | AudioRunnable::Run()] [@ NP_Shutdown | NP_Shutdown | AudioRunnable::Run()] [@ __memcmp16 | NP_Shutdown | AudioRunnable::Run]
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 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.
Attachment #705493 - Flags: approval-mozilla-beta?
Attachment #705493 - Flags: approval-mozilla-aurora?
Attachment #705493 - Flags: approval-mozilla-beta?
Attachment #705493 - Flags: approval-mozilla-beta+
Attachment #705493 - Flags: approval-mozilla-aurora?
Attachment #705493 - Flags: approval-mozilla-aurora+
This looks to be fixed via crash stats.
Keywords: qawanted
It's not fixed. See bp-ba716389-99ae-4d3e-b80e-116652130131.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(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?
(In reply to Robert Kaiser (:kairo@mozilla.com) 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.
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.
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to Robert Kaiser (:kairo@mozilla.com) 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.
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.
The patch hasn't fixed the issue.
I cannot post URLs on this one,  as all with multiple hits are adult websites, judging from the URLs.
Will want to keep an eye on this when 20 gets on Beta.
Current volume on 20 is quite low, untracking.
(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.
Sorry, Scoobidiver, but nothing measured over less than a day qualifies for the topcrash keyword.
(In reply to Robert Kaiser (:kairo@mozilla.com) 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.
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.
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.
Yes, we should not track because it's not new and it's not getting worse.
(In reply to Robert Kaiser (:kairo@mozilla.com) 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.
(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.
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.
Agree with comment 38, no point in further tracking here.
Whiteboard: [native-crash] → [native-crash][unactionable]
Keywords: thirdparty
Keywords: topcrash
filter on [mass-p5]
Priority: -- → P5
Depends on: 1117591
Flash is finally going, Bug 1381916.
Severity: critical → normal
Status: REOPENED → RESOLVED
Closed: 7 years ago2 years ago
Priority: P5 → --
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.