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)

Categories

(Core :: Audio/Video: Playback, defect, P1)

38 Branch
x86
Windows 7
defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox37 - affected
firefox38 - affected
firefox39 - affected

People

(Reporter: alice0775, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

Details

(Keywords: crash)

Crash Data

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)
OS: Windows NT → Windows 7
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)
Component: General → Video/Audio
Blocks: MSE
Priority: -- → P1
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.
Flags: needinfo?(matt.woodrow)
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.
Flags: needinfo?(bobbyholley)
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.
Flags: needinfo?(smooney)
Component: Audio/Video → Audio/Video: Playback
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
See Also: → 1216871
You need to log in before you can comment on or make changes to this bug.