Closed Bug 852915 Opened 12 years ago Closed 11 years ago

[Win7 SP0] crash in mozilla::MediaDecoderReader::DecodeToFirstAudioData

Categories

(Core :: Audio/Video, defect)

Product:
Core
Component:
Audio/Video
Version:
21 Branch
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla23
Tracking Flags:
Tracking Status
firefox20 --- unaffected
firefox21 + fixed
firefox22 --- fixed
firefox23 --- fixed

People

(Reporter: scoobidiver, Assigned: cpearce)

References

Details

(4 keywords, Whiteboard: [qa-])

Crash Data

Attachments

(1 file, 2 obsolete files)

Patch: Disable MP3 on Win7SP0 with MP3 tests disabled on Win7
10.94 KB, patch
cpearce
: review+
bajaj
: approval-mozilla-aurora+
bajaj
: approval-mozilla-beta+
Details | Diff | Splinter Review 
It has been hit several times by different users. It first showed up in 21.0a2/20130224 and 22.0a1/20130313. The Nightly regression range might be:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7433bc4545c9&tochange=c1a5c44ae3d8

Signature 	mozilla::MediaDecoderReader::DecodeToFirstAudioData() More Reports Search
UUID	a45384e6-991f-4db0-9c63-5a5652130320
Date Processed	2013-03-20 09:46:54
Uptime	92
Last Crash	1.9 minutes before submission
Install Age	10.0 hours since version was first installed.
Install Time	2013-03-19 23:49:06
Product	Firefox
Version	22.0a1
Build ID	20130319030939
Release Channel	nightly
OS	Windows NT
OS Version	6.1.7000
Build Architecture	x86
Build Architecture Info	GenuineIntel family 6 model 28 stepping 2
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x0
App Notes 	
AdapterVendorID: 0x8086, AdapterDeviceID: 0x27ae, AdapterSubsysID: 12521043, AdapterDriverVersion: 8.15.10.1930
D3D10 Layers? D3D10 Layers- D3D9 Layers? D3D9 Layers- 
Processor Notes 	sp-processor04.phx1.mozilla.com_789:2008
EMCheckCompatibility	True
Adapter Vendor ID	0x8086
Adapter Device ID	0x27ae
Total Virtual Memory	2147352576
Available Virtual Memory	1821577216
System Memory Use Percentage	35
Available Page File	1376616448
Available Physical Memory	1379020800

Frame 	Module 	Signature 	Source
0 	xul.dll 	mozilla::MediaDecoderReader::DecodeToFirstAudioData 	content/media/MediaDecoderReader.cpp:436
1 	xul.dll 	mozilla::MediaDecoderReader::FindStartTime 	content/media/MediaDecoderReader.cpp:457
2 	xul.dll 	mozilla::MediaDecoderStateMachine::FindStartTime 	content/media/MediaDecoderStateMachine.cpp:2504
3 	xul.dll 	mozilla::MediaDecoderStateMachine::DecodeMetadata 	content/media/MediaDecoderStateMachine.cpp:1841
4 	xul.dll 	mozilla::MediaDecoderStateMachine::DecodeThreadRun 	content/media/MediaDecoderStateMachine.cpp:481
5 	xul.dll 	nsRunnableMethodImpl<void 	obj-firefox/dist/include/nsThreadUtils.h:367
6 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:627
7 	xul.dll 	nsThread::ThreadFunc 	xpcom/threads/nsThread.cpp:265
8 	nss3.dll 	_PR_NativeRunThread 	nsprpub/pr/src/threads/combined/pruthr.c:395
9 	nss3.dll 	pr_root 	nsprpub/pr/src/md/windows/w95thred.c:90
10 	msvcr100.dll 	_callthreadstartex 	f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c:314
11 	msvcr100.dll 	_threadstartex 	f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c:292
12 	kernel32.dll 	BaseThreadInitThunk 	
13 	ntdll.dll 	__RtlUserThreadStart 	
14 	ntdll.dll 	_RtlUserThreadStart 	

More reports at:
https://crash-stats.mozilla.com/report/list?signature=mozilla%3A%3AMediaDecoderReader%3A%3ADecodeToFirstAudioData%28%29
A user on Nightly reported several times Firefox crashes on Facebook:
"Latest update to ver 22 still not working with Facebook. ITS ONLY FB that Ver 22 is having problems with. Everything else is working fine. Something to with msge/post flying up on the left hand side after someone posts. When that happens it crashes. I also have Ver 19 and having absolutely nor problem with it on FB."
It's currently #9 top browser crasher in the first hours of 21.0b1.
tracking-firefox21: --- → ?
Keywords: topcrash
I've been trying to reproduce this for about an hour with Firefox Aurora 22.0a2 2013-04-08 and Firefox Beta 21.0b1 on Windows 7 based on comment 1 but have not had any success yet.
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #3)
> I've been trying to reproduce this for about an hour with Firefox Aurora
> 22.0a2 2013-04-08 and Firefox Beta 21.0b1 on Windows 7 based on comment 1
> but have not had any success yet.

Could a developer comment as to what Facebook functionality might hit the code resulting in this signature?
CCing Chris double here to see if he can help give us some direction given QA has tried reproducing the issue.Chris, can you take a look at this to see if anything obvious happening here leading this crash or provide recommendations on who can help here? thanks !
QA Contact: anthony.s.hughes
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #4)
> Could a developer comment as to what Facebook functionality might hit the
> code resulting in this signature?

From the stack above it looks like the user would be loading an audio file probably (but not definitely) using the new Windows Media Foundation backend. It's not clear to me what type of file they're loading, but it's likely to be an MP3 or something claiming to be an MP3.
Thanks Chris.

I've been unable to reproduce so far trying to interact with some "media" items in my Facebook feed. I'd be willing to share my account info with someone if they'd be willing to share some media items with me so they'd show up in my Notifications panel (based on comment 1).
Status update: I've been unable to reproduce this crash. I wonder if there's some correlation we can find amongst the crash reports, like users may have some DLLs loaded from some external codec pack, or maybe they're running on certain hardware etc, etc...
In the crash reported in comment #0 I see that "Mp3dmod.dll" is loaded, this is Windows Media Foundation's MP3 decoder, so it seems unlikely that an external codec pack is causing this crash.
(In reply to Chris Pearce (:cpearce) from comment #9)
> I wonder if there's some correlation we can find amongst the crash reports, like users
> may have some DLLs loaded from some external codec pack, or maybe they're running on
> certain hardware etc, etc...
Recent correlations have been broken since April 12 (see bug 836671) but here are top correlations per module version on April 10:
 mozilla::MediaDecoderReader::DecodeToFirstAudioData()|EXCEPTION_ACCESS_VIOLATION_READ (84 crashes)
    100% (84/84) vs.   4% (1463/33483) MP3DMOD.DLL
          5% (4/84) vs.   0% (4/33483) 6.1.6956.0
         65% (55/84) vs.   0% (55/33483) 6.1.7000.0
         30% (25/84) vs.   0% (25/33483) 6.1.7022.0
          0% (0/84) vs.   4% (1298/33483) 6.1.7600.16385
    100% (84/84) vs.   7% (2401/33483) devenum.dll
          5% (4/84) vs.   0% (4/33483) 6.6.6956.0
         65% (55/84) vs.   0% (56/33483) 6.6.7000.0
         30% (25/84) vs.   0% (25/33483) 6.6.7022.0
          0% (0/84) vs.   7% (2190/33483) 6.6.7600.16385
    100% (84/84) vs.  15% (4873/33483) mlang.dll
          5% (4/84) vs.   0% (4/33483) 6.1.6956.0
         65% (55/84) vs.   0% (55/33483) 6.1.7000.0
         30% (25/84) vs.   0% (25/33483) 6.1.7022.0
          0% (0/84) vs.   0% (1/33483) 6.1.7100.0
          0% (0/84) vs.   8% (2633/33483) 6.1.7600.16385
    100% (84/84) vs.  20% (6749/33483) mfreadwrite.dll
          5% (4/84) vs.   0% (4/33483) 12.0.6956.7000
         65% (55/84) vs.   0% (56/33483) 12.0.7000.7000
         30% (25/84) vs.   0% (25/33483) 12.0.7022.7000
          0% (0/84) vs.  11% (3848/33483) 12.0.7601.17514
    100% (84/84) vs.  20% (6756/33483) mf.dll
          5% (4/84) vs.   0% (4/33483) 12.0.6956.7000
         65% (55/84) vs.   0% (56/33483) 12.0.7000.7000
         30% (25/84) vs.   0% (25/33483) 12.0.7022.7000
          0% (0/84) vs.   3% (1092/33483) 12.0.7600.16385
          0% (0/84) vs.  12% (3897/33483) 12.0.7601.17514
          0% (0/84) vs.   1% (494/33483) 12.0.9200.16384
    100% (84/84) vs.  20% (6782/33483) mfplat.dll
          5% (4/84) vs.   0% (4/33483) 12.0.6956.7000
         65% (55/84) vs.   0% (56/33483) 12.0.7000.7000
         30% (25/84) vs.   0% (25/33483) 12.0.7022.7000
          0% (0/84) vs.  18% (6184/33483) 12.0.7600.16385
          0% (0/84) vs.   0% (112/33483) 12.0.9200.16384

It happens on Windows 7 SP0 (without SP1).
status-firefox23: --- → affected
Summary: [Win7] crash in mozilla::MediaDecoderReader::DecodeToFirstAudioData → [Win7 SP0] crash in mozilla::MediaDecoderReader::DecodeToFirstAudioData
(In reply to Scoobidiver from comment #11)
> It happens on Windows 7 SP0 (without SP1).

Hmm, in this case, it's probably not tracking-worthy. Let's reevaluate that based on the fact that it only happens on Windows 7 without SP1, as I'm not sure if that's wide-spread enough for us to care that much. (Actually, this fact could be a reason why this crash is apparently decreasing in volume.)

A fix would still be good, but I guess that blocking this functionality from Win7 before SP1 would even be acceptable as a solution.
tracking-firefox21: + → ?
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #12)
> Hmm, in this case, it's probably not tracking-worthy.
I disagree. Facebook is a popular website and Window 7 is supported whatever its service pack (see http://www.mozilla.org/en-US/firefox/21.0beta/system-requirements/)

> I guess that blocking this functionality from Win7 before SP1 would even be acceptable
> as a solution.
It's a good idea.
OK, I will prepare a patch to disable MP3 playback in Firefox on Win7 SP0.

I'm currently working on a DirectShow backend for MP3 playback on platforms without Windows Media Foundation (WinXP), we can use that on Win7SP0 once that ships.
Attached patch Patch: Disable MP3 on Win7SP0 (obsolete) — — Splinter Review 
* Disable MP3 decoding on Windows 7 SP0 using Windows Media Foundation to prevent weird unreproducable crash. Win7SP0 will get MP3 playback once I've got the DirectShow MP3 backend working.
Attachment #738829 - Flags: review?(netzen)
Comment on attachment 738829 [details] [diff] [review]
Patch: Disable MP3 on Win7SP0

Review of attachment 738829 [details] [diff] [review]:
-----------------------------------------------------------------

::: content/media/wmf/WMFDecoder.cpp
@@ +20,5 @@
>  {
>    return new MediaDecoderStateMachine(this, new WMFReader(this));
>  }
>  
> +/* static */ 

nit: get rid of trailing whitespace

@@ +34,5 @@
> +  // We're on Windows 7. MP3 support is disabled if no service pack
> +  // is installed, as it's crashy on Win7 SP0.
> +  UINT spMajorVer = 0, spMinorVer = 0;
> +  WinUtils::GetWindowsServicePackVersion(spMajorVer, spMinorVer);
> +  return spMajorVer != 0 || spMinorVer != 0;

Are we sure that minor != 0 && majorVer == 0 is supported?

::: widget/windows/WinUtils.cpp
@@ +79,5 @@
> +{
> +  OSVERSIONINFOEX osInfo;
> +  osInfo.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX);
> +  // This cast is safe and supposed to be here, don't worry
> +  ::GetVersionEx((OSVERSIONINFO*)&osInfo);

nit:
if (!...) {
  return false;
}

@@ +83,5 @@
> +  ::GetVersionEx((OSVERSIONINFO*)&osInfo);
> +  
> +  aOutMajor = osInfo.wServicePackMajor;
> +  aOutMinor = osInfo.wServicePackMinor;
> +}

return true;

::: widget/windows/WinUtils.h
@@ +49,5 @@
>    };
>    static WinVersion GetWindowsVersion();
>  
> +  // Retrieves the Service Pack version number.
> +  static void GetWindowsServicePackVersion(UINT& aOutMajor, UINT& aOutMinor);

nit: bool
Attachment #738829 - Flags: review?(netzen) → review+
(In reply to Brian R. Bondy [:bbondy] from comment #16)
> Comment on attachment 738829 [details] [diff] [review]
> Patch: Disable MP3 on Win7SP0

> @@ +34,5 @@
> > +  // We're on Windows 7. MP3 support is disabled if no service pack
> > +  // is installed, as it's crashy on Win7 SP0.
> > +  UINT spMajorVer = 0, spMinorVer = 0;
> > +  WinUtils::GetWindowsServicePackVersion(spMajorVer, spMinorVer);
> > +  return spMajorVer != 0 || spMinorVer != 0;
> 
> Are we sure that minor != 0 && majorVer == 0 is supported?

Hmm, I'm not sure. I'll drop the minor version check to be safe. Thanks!
ya I think that's best too, thanks.
Patch with review comments addressed.
Attachment #738829 - Attachment is obsolete: true
Attachment #738860 - Flags: review+
Judging by the failures in https://tbpl.mozilla.org/php/getParsedLog.php?id=21945081&tree=Mozilla-Inbound, we must be running SP0 on our test slaves, and you'll need to adjust the test's expectations to match this new reality.

Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/5dab860f1015
Or file a bug for our test slaves to be at least SP1?
Yes, I think we should get the slaves upgraded to what most users actually are running, and that's SP1.
Dropping qawanted since we've not been able to successfully reproduce this crash internally. Please re-add if something actionable comes to light. Alternatively, once we have successfully landed the patch in comment 19 please add the verifyme keyword. Thank you.
Keywords: qawanted
We're redoing the Win7 test infrastructure in bug 770578 and we should have it up and running by the end of May.

I will make sure that the new infra has SP1 included in it.

Does this work for you? (leave the win7 minis untouched)
To be safe, let's say before end of Q2. It is a goal.
Thanks Armen, I'll disable the failing test case on Win7 in the meantime.
With MP3 tests disabled on Win7. We're still testing MP3 on Win8, and once the DirectShow MP3 decoder lands (hopefully this cycle) I'll revert this and we can test MP3 decoding on Win7 again.

https://tbpl.mozilla.org/?tree=Try&rev=fe24d8016657
Attachment #738860 - Attachment is obsolete: true
Attachment #739386 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/aa774ab6eb72
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla23
Comment on attachment 739386 [details] [diff] [review]
Patch: Disable MP3 on Win7SP0 with MP3 tests disabled on Win7

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 799315; MP4 & MP3 playback support on Windows.
User impact if declined: Win7 SP0 users will have random crashes when playing MP3. Other Windows platforms seem to be unaffected.
Testing completed (on m-c, etc.): Been on nightly for a few days.
Risk to taking this patch (and alternatives if risky): Low risk.
String or IDL/UUID changes made by this patch: None/
Attachment #739386 - Flags: approval-mozilla-beta?
Attachment #739386 - Flags: approval-mozilla-aurora?
The feature of bug 799315 landed in 20.0 while this bug appeared in 21.0. Is there another bug that has caused this?
Blocks: 799315
Flags: needinfo?(cpearce)
This feature is preffed off in 20.
Flags: needinfo?(cpearce)
Comment on attachment 739386 [details] [diff] [review]
Patch: Disable MP3 on Win7SP0 with MP3 tests disabled on Win7

Approving the low risk approach, which disables the feature on Win7 without SP1 to avoid the crashes to those users.Please land before tomorrow morning PT for this to make it into Fx21 Beta 4 which is going to build tomorrow.

Lets keep a close eye on crash-stats to make sure the crashes drop.
Attachment #739386 - Flags: approval-mozilla-beta?
Attachment #739386 - Flags: approval-mozilla-beta+
Attachment #739386 - Flags: approval-mozilla-aurora?
Attachment #739386 - Flags: approval-mozilla-aurora+
D'oh, forgot to qref my beta patch with bustage fixes. I pushed them as a separate  bustage fix:
https://hg.mozilla.org/releases/mozilla-beta/rev/6082f402670e
Tagging this bug [qa-] for verification since we've been unable to identify steps to reproduce. We will need to evaluate based on crash-stats.
Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: