Closed
Bug 1248229
Opened 8 years ago
Closed 8 years ago
"Assertion failure: !mStream->IsDestroyed() (Can't connect a destroyed stream.)" after cycle collection
Categories
(Core :: Audio/Video: Playback, defect, P1)
Core
Audio/Video: Playback
Tracking
()
RESOLVED
FIXED
mozilla47
Tracking | Status | |
---|---|---|
firefox47 | --- | fixed |
People
(Reporter: jruderman, Assigned: jwwang)
Details
(Keywords: assertion, testcase)
Attachments
(4 files)
511 bytes,
text/html
|
Details | |
4.85 KB,
text/plain
|
Details | |
6.98 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
2.85 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
1. Fix the path in the testcase to be correct on your computer 2. Create a profile with: e10 disabled https://www.squarefree.com/extensions/domFuzzLite3.xpi installed 3. Run: firefox -profile <profiledir> w.html 4. Wait one second Assertion failure: !mStream->IsDestroyed() (Can't connect a destroyed stream.), at dom/media/mediasink/OutputStreamManager.cpp:33 Security-sensitive out of caution. Some bugs that involve cycle collection are UAFs, and I don't know whether this one is.
Reporter | ||
Comment 1•8 years ago
|
||
Comment 2•8 years ago
|
||
P1/10 for evaluation. Note: appears to be MediaSink stuff Probably something related to how the OutputStreamManager handles the mStreams list and Disconnect() perhaps being called on it. Wonder if it repros under rr....
Rank: 10
Component: Audio/Video → Audio/Video: Playback
Priority: -- → P1
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → jwwang
Assignee | ||
Comment 3•8 years ago
|
||
Part 1 - add test case to test if playback can work correctly after GC.
Attachment #8720721 -
Flags: review?(roc)
Assignee | ||
Comment 4•8 years ago
|
||
Part 2 - GC might happen in between OutputStreamManager::Disconnect() and OutputStreamManager::Connect(). We need to check if the stream is already destroyed before trying to connect it.
Attachment #8720722 -
Flags: review?(roc)
Assignee | ||
Comment 5•8 years ago
|
||
try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=7c9320d4250b
Attachment #8720722 -
Flags: review?(roc) → review+
Attachment #8720721 -
Flags: review?(roc) → review+
Comment 6•8 years ago
|
||
Could this result in a use-after-free, or just something safer like a null deref?
Assignee | ||
Comment 7•8 years ago
|
||
Thanks for the review!
Assignee | ||
Comment 8•8 years ago
|
||
(In reply to Andrew McCreight [:mccr8] from comment #6) > Could this result in a use-after-free, or just something safer like a null > deref? The later. Here is the try run without the fix (only part 1 is applied): https://treeherder.mozilla.org/logviewer.html#?job_id=16885404&repo=try
Updated•8 years ago
|
Group: media-core-security
https://hg.mozilla.org/integration/mozilla-inbound/rev/85c911ca1bb8 https://hg.mozilla.org/integration/mozilla-inbound/rev/e4345d1fa465
Comment 10•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/85c911ca1bb8 https://hg.mozilla.org/mozilla-central/rev/e4345d1fa465
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
You need to log in
before you can comment on or make changes to this bug.
Description
•