WebAudio Assertion failure: readPosition >= 0.0 (Why are we reading before the beginning of the buffer?) and crash [@mozilla::dom::DelayNodeEngine::ProduceAudioBlock]

RESOLVED FIXED in mozilla24

Status

()

--
critical
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: posidron, Assigned: Ehsan)

Tracking

(Blocks: 1 bug, {crash, testcase})

Trunk
mozilla24
crash, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(2 attachments)

(Reporter)

Comment 1

5 years ago
Created attachment 756948 [details]
testcase

Comment 2

5 years ago
On Windows: bp-e22c67da-101d-4542-b0ef-e46712130601.
Crash Signature: [@ mozilla::dom::DelayNodeEngine::ProduceAudioBlock(mozilla::AudioNodeStream*, mozilla::AudioChunk const&, mozilla::AudioChunk*, bool*) ]
OS: Mac OS X → All
Hardware: x86_64 → All
(Assignee)

Comment 3

5 years ago
So here we have mMaxDelay set to 0.44679999999999997, which means mMaxDelayTime*48000==21446.399999999998, so the buffer length is set to 21446.  Then later on we have writeIndex == 0, and currentDelayTime == 0.44679999999999997 (the max), so readPosition ends up being -0.39999999999781721.  The bug here is that we use NS_lround to calculate the buffer size, which means that if the fraction value of mMaxDelay*sampleRate is less than 0.5, we end up with 1 fewer item in the buffer than expected.
(Assignee)

Comment 4

5 years ago
Created attachment 757045 [details] [diff] [review]
Patch (v1)
Assignee: nobody → ehsan
Status: NEW → ASSIGNED
Attachment #757045 - Flags: review?(roc)
https://hg.mozilla.org/mozilla-central/rev/0fc2452f1385
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
(Assignee)

Comment 7

5 years ago
Mass moving Web Audio bugs to the Web Audio component.  Filter on duckityduck.
Component: Video/Audio → Web Audio
You need to log in before you can comment on or make changes to this bug.