Closed Bug 824877 Opened 7 years ago Closed 7 years ago

crash in mozilla::MediaCache::GetBlockOwner

Categories

(Core :: Audio/Video, defect, critical)

x86
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla21

People

(Reporter: Matti, Assigned: cpearce)

References

Details

(Keywords: crash)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-e09f7ee7-0b84-4fd0-8221-c124b2121227 .
============================================================= 

I crash twice while loading the URL http://slides.html5rocks.com/ .
The crashes occurred directly after loading the page but unfortunately I can not reproduce the crash at the moment :-(

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17a1
Build identifier: 20121224003038

Note: I have h264 playback enabled
Crash Signature: [@ mozilla::MediaCache::GetBlockOwner(int, mozilla::MediaCacheStream*)] → [@ mozilla::MediaCache::GetBlockOwner(int, mozilla::MediaCacheStream*) ]
Duplicate of this bug: 825446
The URL from the duplicate bug: http://hepster.ru:8000/play
Crash Signature: [@ mozilla::MediaCache::GetBlockOwner(int, mozilla::MediaCacheStream*) ] → [@ mozilla::MediaCache::GetBlockOwner(int, mozilla::MediaCacheStream*)]
Blocks: 799315
OK, the problem is pretty straightforward; the stream isn't seekable, so we're returning -1 to WMF in WMFByteStream::GetLength(). WMF is then trying to seek to that offset, not realising that it's invalid, and WMF ends up requesting a read with a negative offset.

If we report to WMF in WMFByteStream::GetCapabilities() that the stream is not as easily seekable when the length is -1 we seem to avoid this chain of events.
Assignee: nobody → cpearce
Depends on: 836927
WFM now, fixed by bug 836927.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
Duplicate of this bug: 869632
You need to log in before you can comment on or make changes to this bug.