This bug was filed from the Socorro interface and is report bp-67c2194a-8ab9-46e8-877f-fd2ae2150125. ============================================================= Seen while looking at crash stats - this seems to have affected the Beta 3 according to the Build IDs (20150122214638). I can't get the full roll up of the URLs, but some I did click on were youtube and some were other media sites. All crashes across branches: https://crash-stats.mozilla.com/report/list?product=Firefox&signature=mozilla::MediaCacheStream::BlockList::RemoveBlock%28int%29 Frame Module Signature Source 0 xul.dll mozilla::MediaCacheStream::BlockList::RemoveBlock(int) dom/media/MediaCache.cpp 1 xul.dll mozilla::MediaCache::NoteBlockUsage(mozilla::MediaCacheStream*, int, mozilla::MediaCacheStream::ReadMode, mozilla::TimeStamp) dom/media/MediaCache.cpp 2 xul.dll mozilla::MediaCacheStream::Read(char*, unsigned int, unsigned int*) dom/media/MediaCache.cpp 3 xul.dll mozilla::MediaCacheStream::ReadAt(__int64, char*, unsigned int, unsigned int*) dom/media/MediaCache.cpp 4 xul.dll mozilla::ChannelMediaResource::ReadAt(__int64, char*, unsigned int, unsigned int*) dom/media/MediaResource.cpp 5 xul.dll mozilla::MP4Stream::BlockingReadIntoCache(__int64, unsigned int, mozilla::Monitor*) dom/media/fmp4/MP4Stream.cpp 6 xul.dll mozilla::InvokeAndRetry<mp4_demuxer::MP4Demuxer, mp4_demuxer::MP4Sample*>(mp4_demuxer::MP4Demuxer*, mp4_demuxer::MP4Sample* ( mp4_demuxer::MP4Demuxer::*)(void), mozilla::MP4Stream*, mozilla::Monitor*) dom/media/fmp4/MP4Reader.cpp 7 xul.dll mozilla::MP4Reader::PopSampleLocked(mp4_demuxer::TrackType) dom/media/fmp4/MP4Reader.cpp
Looks like 'entry' in MediaCacheStream::BlockList::RemoveBlock in nullptr. I don't know enough about MediaCache to say much more, but it seems like we have inconsistent internal state. roc, any idea how that might happen? I don't think we have any STR for this at the moment.
The crash appears to be windows specific (I see 4 OSX crashes with 35 that are a different crash), but that might be due to small numbers of testers on nightly/aurora for other platforms.
(In reply to Matt Woodrow (:mattwoodrow) from comment #1) > Looks like 'entry' in MediaCacheStream::BlockList::RemoveBlock in nullptr. > > I don't know enough about MediaCache to say much more, but it seems like we > have inconsistent internal state. > > roc, any idea how that might happen? Not really, no. Of the first 10 crash reports I looked at, 9 of them had the crash occurring during the first call to NoteBlockUsage from NoteSeek. Unfortunately this looks like corruption of some basic media cache data structures. Each MediaCacheStream maintains three linked lists of all the blocks it's an owner of. If a block has a BlockOwner with that stream, then the block should appear in the appropriate list. Apparently, in these crashes, it doesn't.
How common is this crash?
http://bit.ly/1zmELdc gives the signature summary - in the last 7 days there has been approximately 469 crashes on 36. It is happening in the most recent beta, but not all of the URLs are youtube - there is a mix of other media sites such as https://www.mastermovie-hd.com.
We decided that this is only a problem in the case of non-MSE HTML5 video (since MSE doesn't use the regular media cache), and that we were only experiencing this because YouTube was serving us non-HTML5 video on XP etc. If we run into this again, the answer there is to get them to stop doing it. Decoupling from MSE.
This spiked again in Beta 8, with about 59 crashes.
Still seeing crashes.
Couldn't this be related to bug 1206845? it was fixed around that time. Are those crashes still occurring?
Still happening in 43, 44...
Looks fixed in 45.