476176 - ###!!! ASSERTION: Potential deadlock between media.decoderMonitor@2aaabc33eb40 and Lock@2aaabcf2a300: 'Error', file nsAutoLock.cpp, line 318

Status: RESOLVED FIXED

(Core :: Audio/Video, defect, P2)

Description

[Olli Pettay [:smaug][[e-mail]]]

I get that assertion few times when running mochitest.
The assertion is something quite new.

Comment 1

[Jesse Ruderman]

Attachment: Jesse's stack

I hit this while fuzz-testing or something.

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This particular stack will be fixed by my patch in bug 455654. But it seems that across the board we should never be holding both locks at the same time.

Comment 3

[Justin Dolske [:Dolske]]

With bug 455654, I hit this when a video resumes after a stall in sending data...

http://dolske.net/mozilla/tests/video/slowsend.php?rate=100&stallat=1000000&stallfor=15

This plays for a few seconds, pauses for ~15 seconds, and when it starts getting data again I get a few of these asserts. But it seems to keep working.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

This fixes at least one set of these assertions. We shouldn't call Available() on the stream while holding the decoder lock; we're actually trying to never hold the stream lock at the same time as the decoder lock. We can avoid calling Available altogether by using mDownloadPosition instead, which is protected by the decoder lock.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Pushed http://hg.mozilla.org/mozilla-central/rev/784122b49e33

I'm marking this fixed since we fixed a real bug here. If we hit this assertion again, please file a new bug.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/5201bf6ecd27