Crash when playing silence.wav from VPO Tubular Bells A3

[agittins]

[edit: it looks like the wav file itself that's crashing sfizz]

In Virtual Playing Orchestra, the Tubular Bells patch crashes sfizz when playing A3. In Ardour6, this results in a full crash of Ardour. In sfizz_jack it causes a segfault.

The patch otherwise works fine. The key A3 is defined in a separate group which is used as an "off_by" group for the other velocity groups, but I was able to replicate the issue with the following sfz:

<group>
volume=-2
pan=15
 group=1 lovel=41 ampeg_sustain=.001 ampeg_release=10 ampeg_decay=10 off_by=3
<region> sample=..\libs\NoBudgetOrch\Percussion\TubularBells\silence.wav pitch_keycenter=c4 lokey=c4 hikey=c4

Swapping the silence.wav for another wav file resolves the crash, so it seems sfizz is having issues parsing/playing this particular wav file. I've attached the wav file in question.

silence-wav.zip

[paulfd]

Hi! Thanks for reporting. Is this with the latest release or the develop branch?

[jpcima]

A backtrace of this crash from the jack client
develop b0c84ad

==1049111== Thread 10:
==1049111== Invalid read of size 4
==1049111==    at 0x155246: sfz::Voice::fillWithData(sfz::AudioSpan<float, 2ul>) (src/sfizz/Voice.cpp:482)
==1049111==    by 0x151C4A: sfz::Voice::renderBlock(sfz::AudioSpan<float, 2ul>) (src/sfizz/Voice.cpp:224)
==1049111==    by 0x12F7C8: sfz::Synth::renderBlock(sfz::AudioSpan<float, 2ul>) (src/sfizz/Synth.cpp:595)
==1049111==    by 0x128340: process(unsigned int, void*) (clients/jack_client.cpp:102)
==1049111==    by 0x48A22A9: ??? (in /usr/lib/libjack.so.0.1.0)
==1049111==    by 0x48A1A07: ??? (in /usr/lib/libjack.so.0.1.0)
==1049111==    by 0x48BAB1C: ??? (in /usr/lib/libjack.so.0.1.0)
==1049111==    by 0x496B46E: start_thread (in /usr/lib/libpthread-2.31.so)
==1049111==    by 0x4DD93D2: clone (in /usr/lib/libc-2.31.so)
==1049111==  Address 0x4c is not stack'd, malloc'd or (recently) free'd
==1049111== 
==1049111== 
==1049111== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==1049111==  Access not within mapped region at address 0x4C
==1049111==    at 0x155246: sfz::Voice::fillWithData(sfz::AudioSpan<float, 2ul>) (src/sfizz/Voice.cpp:482)
==1049111==    by 0x151C4A: sfz::Voice::renderBlock(sfz::AudioSpan<float, 2ul>) (src/sfizz/Voice.cpp:224)
==1049111==    by 0x12F7C8: sfz::Synth::renderBlock(sfz::AudioSpan<float, 2ul>) (src/sfizz/Synth.cpp:595)
==1049111==    by 0x128340: process(unsigned int, void*) (clients/jack_client.cpp:102)
==1049111==    by 0x48A22A9: ??? (in /usr/lib/libjack.so.0.1.0)
==1049111==    by 0x48A1A07: ??? (in /usr/lib/libjack.so.0.1.0)
==1049111==    by 0x48BAB1C: ??? (in /usr/lib/libjack.so.0.1.0)
==1049111==    by 0x496B46E: start_thread (in /usr/lib/libpthread-2.31.so)
==1049111==    by 0x4DD93D2: clone (in /usr/lib/libc-2.31.so)
==1049111==  If you believe this happened as a result of a stack
==1049111==  overflow in your program's main thread (unlikely but
==1049111==  possible), you can try to increase the size of the
==1049111==  main thread stack using the --main-stacksize= flag.
==1049111==  The main thread stack size used in this run was 8388608.

[agittins]

Hi! Thanks for reporting. Is this with the latest release or the develop branch?

Hmm. I was using the 0.3.2 release.

I just tried using sfizz_jack from the develop branch as at May 1st (commit 7710282), and it does NOT crash.

Does that pre-date the one jpcima just tested against?

[paulfd]

No he tested develop but as shown by the address sanitizer there is an invalid memory read. Such read can crash or can not crash so it does not mean the bug is absent on develop 🙂

[paulfd]

Can you check the HEAD? We did some changes in b4cc58d
Hopefully this was the issue. @jpcima could reproduce it but I couldn't.

[paulfd]

I'll let you reopen an issue if needed, since this code path moved in the past commits 🙂