Suspected buffer overrun in soundfont loader

[derselbst]

FluidSynth version

2.0.0

Current behavior

Starting fluidsynth with the jack audio driver while loading a sf3 results in a segfault. Also reproducible with a sf2 and dynamic-sample-loading activated.

Steps to reproduce

fluidsynth FluidR3Mono_GM.sf3 -a jack -m jack -l

Other information

git bisect says a985c68 is to blame.

gdb output:

Thread 3 "fluidsynth" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe6a06700 (LWP 19411)]
0x00007ffff5da4222 in Jack::JackLinuxFutex::Connect (this=0x855050, name=name@entry=0x7fffe6a05b54 "system", server_name=server_name@entry=0xa44a40 "default") at ../linux/JackLinuxFutex.cpp:192
192         if (! fPrivate && fFutex->wasInternal)
(gdb) print fFutex
$1 = (Jack::JackLinuxFutex::FutexData *) 0xffffffffffffffff

[derselbst]

Nevermind, that's a bug in jackd: jackaudio/jack2@cc8576a

[mawe42]

Well spotted, thanks! And it seems like the reason why the dynamic-sample-loading triggers this bug is because we allocate smaller chunks of memory. When a sample is below the default memlock limit, that lock succeeds in Fluidsynth but leaves jack with no more room for its fairly small mmap(MAP_LOCKED) calls that trigger the bug.

When starting fluidsynth with synth.lock-memory=0, the crash disappears. This also explains the behaviour in #416 .