Crash/Lock if fluidsynth not initialised

[jhonny-oliveira]

Hi!

I'm not entirely sure this is the right place to ask this but, I'm experiencing the issue below with GZdoom (4.5.0) and it seems to be related to libinstpatch. You can find the full log attached.

There are also other similar reports on the Web: https://forum.zdoom.org/viewtopic.php?t=70710&p=1173878 https://forum.zdoom.org/viewtopic.php?t=68368

Thank you! Jhonny

-------------- LOG --------------

gzdoom_libinstpatch_error.log

fluidsynth: warning: SDL2 not initialized, SDL2 audio driver won't be usable

---

E1M1 - C1M1: Outer Prison

fluidsynth: warning: SDL2 not initialized, SDL2 audio driver won't be usable

(gzdoom:82610): GLib-GObject-WARNING **: 22:20:39.376: cannot register existing type 'IpatchSplitsType'

(gzdoom:82610): GLib-GObject-CRITICAL **: 22:20:39.376: g_param_spec_enum: assertion 'G_TYPE_IS_ENUM (enum_type)' failed

(gzdoom:82610): CRITICAL : 22:20:39.376: ipatch_type_install_property: assertion 'G_IS_PARAM_SPEC(prop_spec)' failed

(gzdoom:82610): GLib-GObject-CRITICAL **: 22:20:39.376: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed

(gzdoom:82610): GLib-GObject-WARNING **: 22:20:39.376: cannot register existing type 'IpatchSF2GenType'

(gzdoom:82610): GLib-GObject-WARNING **: 22:20:39.376: cannot retrieve class for invalid (unclassed) type ''

(gzdoom:82610): CRITICAL : 22:20:39.376: file /build/libinstpatch-i701yY/libinstpatch-1.1.2/libinstpatch/IpatchSF2Gen.c: line 148 (_ipatch_sf2_gen_init): assertion `enum_class != NULL' failed.

(gzdoom:82610): GLib-GObject-WARNING **: 22:20:39.376: cannot register existing type 'IpatchSample'

[derselbst]

Are you on Ubuntu 20.04? Using libinstpatch 1.1.2 and fluidsynth 2.1.1? If so, please update libinstpatch to the latest 1.1.5 and fluidsynth to 2.1.5 and try again.

[jhonny-oliveira]

Hi!

I made the following tests, resulting in the same error:

OS - Ubuntu 20.04 libinstpatch-1.0-2 - 1.1.2-2build1 and 1.1.5-1 libfluidsynth2 - 2.1.1-2

OS - Ubuntu 20.10 libinstpatch-1.0-2 - 1.1.5-1 libfluidsynth2 - 2.1.3-1 and 2.1.5-1

I also packaged and tested with the very latest version of your code.

Cheers! Jhonny

[derselbst]

Cannot reproduce. I've compiled zmusic 1.1.4, gzdoom 4.5.0 using libinstpatch 1.1.5 and fluidsynth 2.1.5. No assertions, no problems.

Which version of zmusic are you using? Which version of gobject? Version of glib?

[jhonny-oliveira]

For gzdoom and zmusic, I used the versions you can find here: https://launchpad.net/~xtradeb/+archive/ubuntu/play. These are not the latest. Their are matching the release tag with minor patches. The remaining deps are distro defaults, either from the matching Ubuntu version or from an higher Ubuntu version. On Ubuntu 20.04, I'm using libglib2.0-0 version 2.66.1-2 (distro default).

Can you share the versions you tested on 20.04 with me (ppa our .debian.tar.)?

[derselbst]

I'm on openSUSE Leap 15.2 using glib + gobject 2.62.5 previously. Now, I've updated glib, gobject, gmodule, gthread, gio, etc. to 2.66.3. Still cannot reproduce this. Please update the glib stuff as well and try again.

[jhonny-oliveira]

Dear @derselbst,

Eventually I realized that the issues was in the latest versions of fluidsynth which does not ship with libfluidsynth1 ABI. So, I also re-packaged it and made it available in xtradeb. Anyone looking for a easy way to install GZDoom should be able to do it from there.

Sorry for the trouble and thank you so much for your help!

[derselbst]

Downgrading to an old and unmaintained version of fluidsynth is definitely not a solution.

[jhonny-oliveira]

Hi!

It is not necessarily a downgrade since libfluidsynth1 and libfluidsynth2 can leave along in Ubuntu. Other than this workaround, which is also proposed in the links below, I don't see another option that wouldn't require code changes. I'm not a developer, neither have a clue were the root cause is....

https://forum.zdoom.org/viewtopic.php?f=7&t=68368 https://www.doomworld.com/forum/topic/114541-solved-gzdoom-fluidsynth-issue-with-ubuntu-2004/

[derselbst]

It is not necessarily a downgrade since libfluidsynth1

You have polluted your ppa with fluidsynth 1.1.11 to compile it against gzdoom / zmusic. This is what I consider as downgrade.

I'm not a developer, neither have a clue were the root cause is....

And you don't have to be. This is my job.

I've set up a virtual machine with ubuntu 20.10. I installed the official gzdoom 4.3.x package. Works. Used your gzdoom, still works, but only because it's using libfluidsynth1. Removed that, to make it force to libfluidsynth2 and finally I was able to reproduce this. Installed debug symbols and source code and here we go:

Thread 1 "gzdoom" hit Breakpoint 3, new_fluid_synth (settings=0x55555c768830) at ./src/synth/fluid_synth.c:606
606 {
(gdb) bt
#0  new_fluid_synth (settings=0x55555c768830) at ./src/synth/fluid_synth.c:606
#1  0x00007ffff77fc8bb in FluidSynthMIDIDevice::FluidSynthMIDIDevice(int, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&) () from /opt/gzdoom/libzmusic.so.1
#2  0x00007ffff77fce7e in CreateFluidSynthMIDIDevice(int, char const*) () from /opt/gzdoom/libzmusic.so.1
#3  0x00007ffff780bc1f in MIDIStreamer::CreateMIDIDevice(EMidiDevice_, int) () from /opt/gzdoom/libzmusic.so.1
#4  0x00007ffff780cdfb in MIDIStreamer::Play(bool, int) () from /opt/gzdoom/libzmusic.so.1
#5  0x00007ffff7810f58 in ZMusic_Start () from /opt/gzdoom/libzmusic.so.1
#6  0x0000555555c9e9b1 in S_ChangeMusic(char const*, int, bool, bool) ()
#7  0x0000555555a45c0b in D_DoAdvanceDemo() ()
#8  0x0000555555a51083 in TryRunTics() ()
#9  0x0000555555a46033 in D_DoomLoop() ()
#10 0x0000555555a49a1d in ?? ()
#11 0x0000555555a4ab39 in GameMain() ()
#12 0x00005555557fe162 in main ()
(gdb) n

This is the first call to new_fluid_synth(). We must initialize ourselves.

615     if(fluid_atomic_int_compare_and_exchange(&fluid_synth_initialized, 0, 1))
(gdb) print fluid_synth_initialized
$1 = 1 # The synth hasn't been initialized yet. This is now being done.

As part of that initialization, libinstpatch is also initialized. And libinstpatch in turn initializes gobject:

Thread 1 "gzdoom" hit Breakpoint 1, ipatch_init () at ./libinstpatch/misc.c:180
180 {
187     init_counter++;
(gdb) 
188     if(init_counter > 1)
(gdb) print init_counter
$2 = 1
(gdb) c
Continuing.

Now, the fluidsynth, libinstpatch and gobject have been initialized successfully.

[New Thread 0x7fffd1bfd640 (LWP 2245)]
warning: Temporarily disabling breakpoints for unloaded shared library "/lib/x86_64-linux-gnu/libfluidsynth.so.2"
warning: Temporarily disabling breakpoints for unloaded shared library "/lib/x86_64-linux-gnu/libinstpatch-1.0.so.2"

!!! But what is this ^^^ ?? The fluidsynth library is unloaded by zmusic, as well as libinstpatch. Thus both libs forget that they have been already initialized.

----------------------------------------

E1M1 - C1M1: Outer Prison

fluidsynth: warning: SDL2 not initialized, SDL2 audio driver won't be usable

Thread 1 "gzdoom" hit Breakpoint 3, new_fluid_synth (settings=0x55555eabdab0) at ./src/synth/fluid_synth.c:606
606 {
...

Starting the Outer Prison, another synth is being created. And ofc. it is initializing itself again, as well as it is initializing libinstpatch.

Thread 1 "gzdoom" hit Breakpoint 1, ipatch_init () at ./libinstpatch/misc.c:180
180 {
### and also libinstpatch has forgotten, it has already been initialized. Hence it's initialing itself again.
187     init_counter++;
(gdb) 
188     if(init_counter > 1)
(gdb) print init_counter
$4 = 1
(gdb) n
195     g_type_init();
(gdb) 
210     _ipatch_param_init();
(gdb) 
213     _ipatch_type_prop_init();
(gdb) 

glib, gobject and friends however have not been unloaded, and therefore they already know about the libinstpatch objects. And because of that, bad things happen when libinstpatch wants to initialize again...

(process:2224): GLib-GObject-WARNING **: 14:18:55.001: cannot register existing type 'IpatchSplitsType'

(process:2224): GLib-GObject-CRITICAL **: 14:18:55.001: g_param_spec_enum: assertion 'G_TYPE_IS_ENUM (enum_type)' failed

** (process:2224): CRITICAL **: 14:18:55.001: ipatch_type_install_property: assertion 'G_IS_PARAM_SPEC(prop_spec)' failed

@coelckers I think this is your bug. I don't see anything we could do here. Either you make sure to unload all dependency libraries of fluidsynth, esp. glib, gobject and friends. Or, preferably, you get rid of that late binding stuff at all.

@jhonny-oliveira Compile zmusic with DYN_FLUIDSYNTH=0. And, pls., also compile with DYN_SNDFILE=0 and DYN_MPG123=0

[jhonny-oliveira]

I removed the libfluidsynth1 dependency and set the flags you recommended in zmusic (and in gzdoom). The game is playable, but I can see this error in the log: Unable to create FluidSynth MIDI device. Falling back to Timidity++.

This is pretty similar to running the game without: libfluidsynth1 and fluid-soundfont-gs/m. I get the some warnings, including "fluidsynth: warning: SDL2 not initialized" but the game still runs.

Looking forward for patches and/or directions :-)

[jhonny-oliveira]

I realized that when I split zmusic and gzdoom I mixed up the build flags and dependencies a bit. I made a few adjustments and rebuilt the packages.

No more freezes or crashes and I also left out and removed libfluidsynth1. The only warning I get in Ubuntu now is:

fluidsynth: warning: SDL2 not initialized, SDL2 audio driver won't be usable

Please have a look at my packaging definitions, game install startup log and let me know if there is anything I can improve on my side (cc: @coelckers).

https://launchpad.net/~xtradeb/+archive/ubuntu/play/+sourcefiles/zmusic/1.1.4-1~xtradeb3/zmusic_1.1.4-1~xtradeb3.debian.tar.xz https://launchpad.net/~xtradeb/+archive/ubuntu/play/+sourcefiles/gzdoom/4.5.0-1~xtradeb5/gzdoom_4.5.0-1~xtradeb5.debian.tar.xz

GZDoom_4.5.0_log_20201216.log

[derselbst]

Please have a look at my packaging definitions, game install startup log

Looks good to me. Also I've tried it in my VM and it's running fine there too.