862709 - crash in mozilla::BufferMediaResource::Read

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[Scoobidiver (away)]

It first showed up in 23.0a1/20130414 and 22.0a2/20130416. The regression ranges might be (low volume):
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=24a6b5ed51e3&tochange=ef802a6418f2
http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=b6d86fda0787&tochange=59a419eca635

Signature 	_VEC_memcpy | mozilla::BufferMediaResource::Read(char*, unsigned int, unsigned int*) More Reports Search
UUID	42163e26-49c0-4523-b452-64ba42130416
Date Processed	2013-04-16 22:32:12
Uptime	67
Last Crash	1.2 minutes before submission
Install Age	6.5 minutes since version was first installed.
Install Time	2013-04-16 22:25:07
Product	Firefox
Version	23.0a1
Build ID	20130416030901
Release Channel	nightly
OS	Windows NT
OS Version	6.1.7601 Service Pack 1
Build Architecture	x86
Build Architecture Info	GenuineIntel family 6 model 15 stepping 2
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x22179010
App Notes 	
AdapterVendorID: 0x10de, AdapterDeviceID: 0x0de1, AdapterSubsysID: 00000000, AdapterDriverVersion: 9.18.13.697
D2D? D2D+ DWrite? DWrite+ D3D10 Layers? D3D10 Layers+ 
Processor Notes 	sp-processor01.phx1.mozilla.com_16394:2012; exploitability tool failed: 127
EMCheckCompatibility	True
Adapter Vendor ID	0x10de
Adapter Device ID	0x0de1
Total Virtual Memory	4294836224
Available Virtual Memory	3268071424
System Memory Use Percentage	61
Available Page File	2986811392
Available Physical Memory	1226485760

Frame 	Module 	Signature 	Source
0 	msvcr100.dll 	_VEC_memcpy 	
1 	xul.dll 	mozilla::BufferMediaResource::Read 	obj-firefox/dist/include/BufferMediaResource.h:63
2 	xul.dll 	mozilla::OggReader::ReadOggPage 	content/media/ogg/OggReader.cpp:882
3 	xul.dll 	mozilla::OggReader::ReadMetadata 	content/media/ogg/OggReader.cpp:187
4 	xul.dll 	mozilla::MediaDecodeTask::Decode 	content/media/webaudio/MediaBufferDecoder.cpp:427
5 	nss3.dll 	PR_ExitMonitor 	nsprpub/pr/src/threads/prmon.c:100
6 	xul.dll 	nsThreadPool::Run 	xpcom/threads/nsThreadPool.cpp:194
7 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:627
8 	xul.dll 	nsThread::ThreadFunc 	xpcom/threads/nsThread.cpp:265
9 	nss3.dll 	_PR_NativeRunThread 	nsprpub/pr/src/threads/combined/pruthr.c:395
10 	nss3.dll 	pr_root 	nsprpub/pr/src/md/windows/w95thred.c:90
11 	msvcr100.dll 	_callthreadstartex 	f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c:314
12 	msvcr100.dll 	_threadstartex 	f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c:292
13 	kernel32.dll 	BaseThreadInitThunk 	
14 	ntdll.dll 	__RtlUserThreadStart 	
15 	ntdll.dll 	_RtlUserThreadStart 	

More reports at:
https://crash-stats.mozilla.com/report/list?signature=_VEC_memcpy+|+mozilla%3A%3ABufferMediaResource%3A%3ARead%28char*%2C+unsigned+int%2C+unsigned+int*%29
https://crash-stats.mozilla.com/report/list?signature=memcpy+|+mozilla%3A%3ABufferMediaResource%3A%3ARead%28char*%2C+unsigned+int%2C+unsigned+int*%29

Comment 1

[Chris Pearce [:cpearce (Not reading bugmail)]]

Possibly this will be fixed by Bug 862182.

Comment 2

[Chris Pearce [:cpearce (Not reading bugmail)]]

Moving to security, just in case..

Comment 3

[Andrew McCreight [:mccr8]]

Marking dependency.  If that's the problem, then this is sec-critical.

Comment 4

[David Bolter [:davidb] (NeedInfo me for attention)]

Bug 862182 has its fix approved for landing. Let's hope for comment 1.

Comment 5

[Scoobidiver (away)]

There are no crashes after 23.0a1/20130416 and 22.0a2/20130416.

Comment 6

[Chris Pearce [:cpearce (Not reading bugmail)]]

Ehsan: given Scoobidiver's fix range above, do you think this was fixed by this changeset?

changeset:   128881:ee39d8eb931f
user:        Ehsan Akhgari <[e-mail]>
date:        Mon Apr 15 20:08:03 2013 -0400
summary:     Bug 854319 - Part 2: Always use a ref pointer when dealing with MediaResource objects; r=cpearce

Comment 7

[(no longer active)]

Yes, sorry, I think I made a mistake when I looked at the stacks here previously.  This is clearly related to decodeAudioData, therefore the fact that bug 854319 has fixed this is in fact the exact expected result.

Comment 8

[Lukas Blakk [:lsblakk] use ?needinfo]

Since this is sec-critical should we (can we) uplift to aurora safely?  Could the esr branch affected by this crash? I don't see it in the crash stats but if we can land this safely on esr17 should we do so to cover our bases for this?

Comment 9

[(no longer active)]

(In reply to [e-mail] from comment #8)
> Since this is sec-critical should we (can we) uplift to aurora safely? 
> Could the esr branch affected by this crash? I don't see it in the crash
> stats but if we can land this safely on esr17 should we do so to cover our
> bases for this?

esr17 is unaffected.  The buggy code exists on 22, but it's disabled by default, so the bug doesn't bite anybody there unless they have manually toggled the media.webaudio.enabled pref.  I'm not sure what we usually do for these kinds of uplifts.

Comment 10

[u279076]

Is there a known testcase QA can use to verify this is fixed?

Comment 11

[u279076]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #10)
> Is there a known testcase QA can use to verify this is fixed?

Ehsan, do you know if there's any way QA can verify this fix?

Comment 12

[Andrew McCreight [:mccr8]]

There's a test case in the bug mentioned in comment 7 (that has been verified, it looks like), but this bug is based entirely on crash-stats, so no.

Comment 13

[Scoobidiver (away)]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #11)
> Ehsan, do you know if there's any way QA can verify this fix?
You can't based on crash stats. Note that remaining crashes are tracked in bug 882589.

Comment 14

[u279076]

Thanks Andrews and Scoobidiver, tagging [qa-] based on this info.