Closed
Bug 495161
Opened 17 years ago
Closed 17 years ago
Wave decoder deadlock looping between PLAYING and BUFFERING
Categories
(Core :: Audio/Video, defect)
Core
Audio/Video
Tracking
()
VERIFIED
FIXED
mozilla1.9.2a1
People
(Reporter: roc, Assigned: roc)
Details
(Keywords: verified1.9.1)
Attachments
(1 file)
|
1.55 KB,
patch
|
kinetik
:
review+
beltzner
:
approval1.9.1+
|
Details | Diff | Splinter Review |
I found a deadlock in the Wave decoder. Basically the Wave decoder keeps cycling between PLAYING and BUFFERING without releasing the decoder lock. The cycling happens because PLAYING starts buffering if mStream->GetCachedDataEnd(mPlaybackPosition) < mPlaybackPosition + len, and sets mBufferingEndOffset to mPlaybackPosition + TimeToBytes(mBufferingWait.ToSeconds()), then BUFFERING stops buffering as soon as mStream->GetCachedDataEnd(mPlaybackPosition) >= mBufferingEndOffset. It is possible for these to be true at the same time, when TimeToBytes(mBufferingWait.ToSeconds()) < len.
So this patch makes sure that mBufferingEndOffset is always at least >= mPlaybackPosition + len, which means we'll buffer at least until we receive the data whose absence caused us to start buffering in the first place.
Flags: wanted1.9.1+
| Assignee | ||
Comment 1•17 years ago
|
||
Attachment #380016 -
Flags: review?(kinetik)
Comment 2•17 years ago
|
||
Comment on attachment 380016 [details] [diff] [review]
fix
Looks fine, but it seems like the patch could just be:
+ mBufferingEndOffset = PR_MAX(mPlaybackPosition + len, mBufferingEndOffset);
Attachment #380016 -
Flags: review?(kinetik) → review+
| Assignee | ||
Comment 3•17 years ago
|
||
It could be, but I think it's clearer this way since mPlaybackPosition + len occurs in two places.
| Assignee | ||
Comment 4•17 years ago
|
||
Comment on attachment 380016 [details] [diff] [review]
fix
We should get this into 1.9.1. Very small safe fix, avoids leaking a CPU-eating thread, so pretty important.
Attachment #380016 -
Flags: approval1.9.1?
Updated•17 years ago
|
Attachment #380016 -
Flags: approval1.9.1? → approval1.9.1+
Comment 5•17 years ago
|
||
Comment on attachment 380016 [details] [diff] [review]
fix
a191=beltzner
| Assignee | ||
Comment 6•17 years ago
|
||
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Whiteboard: [needs 191 landing]
Comment 7•17 years ago
|
||
Pushed to 1.9.1: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/cd8b3f5c9d5e
Whiteboard: [needs 191 landing]
Comment 8•17 years ago
|
||
Are we good here? Did we forget a fixed-1.9.1 somewhere?
| Assignee | ||
Updated•17 years ago
|
Keywords: fixed1.9.1
Comment 9•17 years ago
|
||
Verified fixed on trunk and 1.9.1 based on checkins and green boxes.
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
OS: Mac OS X → All
Hardware: x86 → All
Target Milestone: --- → mozilla1.9.2a1
You need to log in
before you can comment on or make changes to this bug.
Description
•