Closed Bug 1133305 Opened 6 years ago Closed 5 years ago
[Youtube HTML5 video] crash in std::_Atomic
_fetch _sub _4(unsigned long volatile*, unsigned long, std::memory _order)
This bug was filed from the Socorro interface and is report bp-58646ca7-b331-4c94-a9dd-edf1c2150215. ============================================================= Crash while Playback youtube and Navigate links(10-20) within youtube with newly created profile (e10s is blocked by IME detection)
Summary: crash in std::_Atomic_fetch_sub_4(unsigned long volatile*, unsigned long, std::memory_order) → [Youtube HTML5 video] crash in std::_Atomic_fetch_sub_4(unsigned long volatile*, unsigned long, std::memory_order)
Bobby, we are trying to figure out if this is issue or not. Are you the right person to investigate.
Looks like a double-free or corruption releasing the MediaDecoderReader.
6 years ago
This line appears to be triggering the runnable destructor: http://hg.mozilla.org/mozilla-central/annotate/a7c177546ca0/dom/media/MediaTaskQueue.cpp#l55 Which it's not supposed to do. So presumably the push is failing or something.
Flags: needinfo?(matt.woodrow) → needinfo?(bobbyholley)
I didn't mean to take the needinfo, but I could probably poke into this a little bit more in the next day or two. Feel free to steal it back if you want, Matt.
Feel free to keep looking at this, I have no idea how we end up calling Release on the runnable at that line.
Hm yeah - Release on the runnable makes sense, because we're constructing a temporary TaskQueueEntry that's eventually going to get destroyed, but the refcount should remain above zero, so I don't see how we'd be triggering the destructor. There may be other heap corruption involved, or the stack may be lying. Let's not worry about this unless we see more of it.
Triage team requested crash volume for this signature: https://crash-stats.mozilla.com/report/list?signature=std::_Atomic_fetch_sub_4%28unsigned%20long%20volatile*,%20unsigned%20long,%20std::memory_order%29 A few reports are in 37 while the lion's share are in 36. I also added another signature to the crash signatures field.
Crash Signature: [@ std::_Atomic_fetch_sub_4(unsigned long volatile*, unsigned long, std::memory_order)] → [@ std::_Atomic_fetch_sub_4(unsigned long volatile*, unsigned long, std::memory_order)] [@ shutdownhang | std::_Atomic_fetch_sub_4(unsigned long volatile*, unsigned long, std::memory_order) ]
Untracking low volume crash for 37. Note that this crash appears in 36.0.1 in which MSE is disabled so this is not MSE specific. Sheila - This is marked as an MSE P1. That prioritization should probably be reviewed.
I can't see how this could happen with recent (>= 41) and the MediaFormatReader (MP4Reader has been removed)
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.