[Youtube HTML5 video] crash in std::_Atomic_fetch_sub_4(unsigned long volatile*, unsigned long, std::memory_order)

RESOLVED FIXED

Status

()

defect
P1
critical
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: alice0775, Unassigned, NeedInfo)

Tracking

(Blocks 1 bug, {crash})

38 Branch
x86
Windows 7
Points:
---

Firefox Tracking Flags

(firefox37- affected, firefox38- affected, firefox39- affected)

Details

(crash signature)

(Reporter)

Description

4 years ago
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)
(Reporter)

Updated

4 years ago
OS: Windows NT → Windows 7
(Reporter)

Updated

4 years ago
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)
(Reporter)

Updated

4 years ago
Component: General → Video/Audio

Updated

4 years ago
Priority: -- → P1

Comment 1

4 years ago
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
Last Resolved: 4 years ago
Resolution: --- → FIXED

Updated

4 years ago
See Also: → 1216871
You need to log in before you can comment on or make changes to this bug.