Closed Bug 1145203 Opened 5 years ago Closed 5 years ago

Stop synchronously draining the decode task queue when spinning down the MDSM


(Core :: Audio/Video, defect)

Not set



Tracking Status
firefox39 --- fixed


(Reporter: bholley, Assigned: bholley)




(2 files)

It's causing trouble in bug 1142336, and I don't think we need to do it anymore.
Try push for this was here:

This had b2g crashes in dom/media/test/test_standalone.html, and I looked into them with logging here:

What's happening is basically the nightmare scenario for the MDSM: SetDormant(true) and a subsequent SetDormant(false) both run while we're in the middle of DecodeMetadata (on the decode thread, with monitor dropped). And it just so happens that our DecodeMetadata task wakes up when we've just arrived _back_ in DECODER_STATE_DECODING_METADATA. And so it incorrectly assumes that nothing interesting happened while it was sleeping (this is the nightmare part) and goes about its merry way issuing requests that the decode pipeline is totally not ready for. Boom.

To be clear, this is an existing bug on trunk - the patches in this bug just made it faster to go into dormant mode (because the work is now pipelined, instead of waiting for the task queue to drain), and so we're more likely to trigger it.

The answer here is to fix up metadata decoding to use promises and not be totally insane. That's bug 1136873, already on file. The rabbit hole goes one step deeper.
Depends on: 1136873
There are two callers of FlushDecoding - One is shutdown (where we already use
promises to wait for the queue to go idle via BeginShutdown), and the other is
dormant (see the comment).
Attachment #8581239 - Flags: review?(matt.woodrow)
Attachment #8581239 - Flags: review?(matt.woodrow) → review+
Attachment #8581240 - Flags: review?(matt.woodrow) → review+
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
You need to log in before you can comment on or make changes to this bug.