LMMS freezes when creating a new project on Arch Linux

[LunatiK-ExpiX]

LMMS Freezes when creating a new file

1. Have loaded a Soundfont default file in permissions (might not be required) 2. Load any midi, preferably above 40kb 3. Change soundfont bank/patch on multiple tracks 4. Create new project 5. Repeat

New Project is created

Program freezes instantly, killing the application fixes the issue.

Version 1.2.2 (Linux/x86_64, Qt 5.15.4, GCC 12.1.0) Install command - [yay -S lmms], Origin: Official (Community)

No log file was produced, It would freeze before it could be produced

[allejok96]

Could you download the 1.3 appimage and test if you can reproduce the bug?

[PhysSong]

I can also reproduce this bug with 1.3. LMMS sometimes freezes while trying to unload a soundfont using delete_fluid_synth(), inside fluid_thread_join() on a timer thread. I haven't tested this with debug builds of FluidSynth yet, so I will post more details once I figure out what's going on.

[UltimateBoomer]

On my Pop OS 22.04 system, if I build LMMS 1.3 from source and run it, I can reproduce this bug. The freezing randomly occurs when I create a new project or load another project. However, for some reason this bug does not happen on the AppImage builds.

[PhysSong]

However, for some reason this bug does not happen on the AppImage builds.

The AppImage build uses FluidSynth 1, while your build is likely to use FluidSynth 2. I think this might be the difference.

[PhysSong]

I've investigated this bug further and found the problem. For some reason, sample->refcount is negative in https://github.com/FluidSynth/fluidsynth/blob/a85aa9811ca511809964fd55f692120baa362640/src/sfloader/fluid_defsfont.c#L250-L253 when LMMS hangs. This only happens when playing multiple instances of SF2 player which shares the same soundfont simultaneously. FluidSynth prevents simultaneous accesses to a fluid_synth_t using fluid_synth_api_enter, but it seems like it doesn't prevent race conditions on shared resources between multiple fluid_synth_ts.

I'll report this bug to the upstream to know if it's their bug or our bug or both.

[PhysSong]

This issue is much easier to reproduce when you create one track using SF2 player and clone it many times(10 copies were enough in my case).

[PhysSong]

Quoting a comment from the upstream:

you keep adding the same fluid_sfont_t to multiple synths through fluid_synth_add_sfont. But this is illegal. Cf. the API docs of that function:

ownership is transferred to synth.

Do not try to share soundfonts between synths. Instead, call fluid_synth_sfload everytime when loading a new font. Fluidsynth shares the samples between all synths via its internal sample cache.

Also, another comment says the feature has existed since FluidSynth 1.1.7, which was released in 2017. So I think we can follow the upstream recommendation and optionally bump up the FluidSynth version requirement.