Closed Bug 824877 Opened 12 years ago Closed 11 years ago

crash in mozilla::MediaCache::GetBlockOwner

Categories

(Core :: Audio/Video, defect)

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

Tracking

()

Status:
RESOLVED FIXED
Milestone:
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*) ]
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: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
You need to log in before you can comment on or make changes to this bug.