Panic in AudioBufferSourceNode

[jipodine]

While trying to play a looped bufferSourceNode, I got the following error:

Panic occurred in Audio Processor: 'index out of bounds: the len is 26332 but the index is 26368'. Removing node from graph.

And it failed to quit or crash the application

fatal runtime error: failed to initiate panic, error 1073786336

Hard to replicate, but it seems that the loop bound is not safely clipped.

[orottier]

Hi @jipodine, thanks for flagging this with us. This is probably an issue with the underlying rust audio implementation.
You say it is hard to replicate, but could you provide us with some more details:

• which version are you running?
• which loop parameters are set? (loop, loopStart, loopEnd)
• what start call was made? start(when, offset, duration)
• which of the audio params are set? (detune, playbackrate)
• does it panic at the first loop iterations, or after several?

[jipodine]

Hi, Thank you for you help.

* which version are you running?

0.20.0

* which loop parameters are set? (loop, loopStart, loopEnd)

only `loop` (true)

* what |start| call was made? |start(when, offset, duration)|

I do not know exactly, but it could be possible that I tried to start a with a very big `offset` (to synchronise with already playing sounds). `when` is between audioContext.now and (audioContext.now + 1) `duration` is undefined.

* which of the audio params are set? (detune, playbackrate)

none

* does it panic at the first loop iterations, or after several?

I do not know, but a guess would be at the first one with a very big offset.

[jipodine]

It might also be that I played the sound in loop for a long time: like 2 hours for a 1 minute buffer.

[b-ma]

Hey, thanks for the feedback

@otto, rapidly checking the Rust code, unless I missed something it seems we don't actually make all the checks and clamping defined here: https://webaudio.github.io/web-audio-api/#dom-audiobuffersourcenode-start-when-offset-duration-offset, can you have another look?

[orottier]

Sure, I'm having a look.

I'm writing a fuzzer now that tests the whole range of possible configurations, and I have already found a case where processing hangs indefinitely. I have yet to track the panic condition, but will indeed look at clamping first.

[jipodine]

About clamping, #135 might be related.

[orottier]

Apologies, I have not been able to spend a lot of time on this.
I added a comment to #135 which I believe is not directly related (but thanks for flagging!)
I have not been able to reproduce the panic. Clamping appears to be handled in both the fast-path the not-fast-path.
TBC

[b-ma]

(hopefully) fixed in v0.21.2

Let's re-open if we see it again