Closed Bug 1179482 Opened 7 years ago Closed 7 years ago

crash in mozilla::MediaFormatReader::ReleaseMediaResources()


(Core :: Audio/Video, defect)

Windows NT
Not set



Tracking Status
e10s - ---
firefox40 --- unaffected
firefox41 + fixed
firefox42 --- affected


(Reporter: jesper, Unassigned)


(Keywords: crash)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-560df307-fcd3-401f-a03c-11b712150701.
More crashes:

I had running in the background, and once it hit around 1:10:00 to 1:20:00, then all the content tabs crashed.
I believe this could be related to some of the "out of sync" videos.
You may actually have to let the video run for the entire duration for it to crash :/
top crash on aurora with e10s and non-e10s.
tracking-e10s: --- → ?
[Tracking Requested - why for this release]:
We should track for the release in general as it's a topcrash on both the browser and content process, with and without e10s, about 4% of overall crashes of both processes.
It should be noted that this crash is not background-specific. I just had it during foreground YouTube video playback.
Sorry for double post but I forgot to add specific YouTube video that crashes for me:

The interesting part is that I found that this specific video (in 1080p60 mode) crashes after couple of minutes of watching even after fresh restart:

1) -- initial crash;

2) -- crash after fresh restart (due to previous crash).

I have watched couple of dozens of other videos earlier today (though they were regular 30 FPS, not 60 FPS playback as this one) and none of them has crashed FireFox.
Adding a tracking flag for FF41 as this was identified as a top crash in comment 2.
Description of this bug states that "Version: unspecified", but I just confirmed that YouTube video that crashes in Nightly in my case does not crash in release version 39, so the "Version" can be set to 41 and above.
We're not using the Version field much, we use the status flags for marking which versions are affected.
  1448 void MediaFormatReader::ReleaseMediaResources()
  1449 {
  1450   // Before freeing a video codec, all video buffers needed to be released
  1451   // even from graphics pipeline.
  1452   VideoFrameContainer* container = mDecoder->GetVideoFrameContainer();

mDecoder is null
Flags: needinfo?(cpearce)
I thought MediaFormatReader wasn't enabled on Nightly yet? So I'm surprised we have crash reports already.

We can probably just null-check mDecoder here.
Flags: needinfo?(cpearce) → needinfo?(jyavenard)
MediaFormatReader is the default for anything related to mp4.

But didn't I submitted a patch for exactly that problem last week?
Flags: needinfo?(jyavenard)
Ah yes: 
bug 1180403
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1180403
Since not everyone might be able to see the duplicate bug: I've confirmed that these stopped on nightly after bug 1180403 landed.
You need to log in before you can comment on or make changes to this bug.