Closed
Bug 1068981
Opened 10 years ago
Closed 10 years ago
Crash in MediaStreamGraphImpl::CollectReports when collecting DMD reports
Categories
(Core :: Audio/Video, defect)
Tracking
()
RESOLVED
FIXED
mozilla35
Tracking | Status | |
---|---|---|
firefox33 | --- | unaffected |
firefox34 | --- | fixed |
firefox35 | --- | fixed |
b2g-v2.1 | --- | fixed |
b2g-v2.2 | --- | fixed |
People
(Reporter: rbarker, Assigned: erahm)
References
Details
Attachments
(3 files)
150.92 KB,
text/plain
|
Details | |
140 bytes,
text/plain
|
Details | |
1.11 KB,
patch
|
roc
:
review+
khuey
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
Running DMD on MacOS X will crash on an assert in when MediaStreamGraphImpl::CollectReports calls CurrentDriver()->WakeUp();
Reporter | ||
Comment 1•10 years ago
|
||
I have been unable to reproduce. I did not save the stack trace when I first encountered this and now that I'm trying to reproduce it, I am unable to.
Assignee | ||
Comment 2•10 years ago
|
||
Randall, do you have any sort of STR for this? Maybe a specific page or test?
Summary: DMD crashes on MacOS X when collecting reports → Crash in MediaStreamGraphImpl::CollectReports when collecting DMD reports
Reporter | ||
Comment 3•10 years ago
|
||
(In reply to Eric Rahm [:erahm] from comment #2)
> Randall, do you have any sort of STR for this? Maybe a specific page or test?
I was debugging a memory leak while streaming a tab. I didn't save the stack trace and when I later tried to reproduce for the bug, I was unable to. I may have been the victim of a timing related bug that is difficult to reproduce? The media pipeline was busy encoding a tab while I was attempting to save a report so maybe that increased the chance of hitting the mGraphImpl->GetMonitor().AssertCurrentThreadOwns(); ?
Reporter | ||
Comment 4•10 years ago
|
||
Realized I forgot to uncomment the line causing problems yesterday when trying to reproduce. After uncommenting, reproduced on first try.
Reporter | ||
Comment 5•10 years ago
|
||
Assignee | ||
Comment 6•10 years ago
|
||
This appears to be some sort of fallout from bug 848954, previously we would grab a lock before calling |WakeUp|.
Blocks: 848954
Assignee | ||
Comment 7•10 years ago
|
||
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → erahm
Status: NEW → ASSIGNED
Assignee | ||
Comment 8•10 years ago
|
||
Randall, would you mind testing this patch to see if it fixes your issue? I've confirmed it builds, runs, and an about:memory report worked w/o crashing.
Flags: needinfo?(rbarker)
Reporter | ||
Comment 9•10 years ago
|
||
(In reply to Eric Rahm [:erahm] from comment #8)
> Randall, would you mind testing this patch to see if it fixes your issue?
> I've confirmed it builds, runs, and an about:memory report worked w/o
> crashing.
It appears to fix the crash I was seeing. I ran without the patch and crashed as before. After applying the patch was able to run multiple times without issue.
Flags: needinfo?(rbarker)
Assignee | ||
Updated•10 years ago
|
Attachment #8495632 -
Flags: review?(roc)
Attachment #8495632 -
Flags: review?(roc) → review+
Assignee | ||
Comment 10•10 years ago
|
||
Comment 12•10 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
Comment on attachment 8495632 [details] [diff] [review]
Acquire monitor before calling WakeUp
This is blocking CAF stability testing. a=me for uplift.
Attachment #8495632 -
Flags: approval-mozilla-aurora+
Comment 14•10 years ago
|
||
Updated•10 years ago
|
status-b2g-v2.1:
--- → fixed
status-b2g-v2.2:
--- → fixed
You need to log in
before you can comment on or make changes to this bug.
Description
•