frequent segfaults with 1.0.0, maybe caused by plugin ?

[fenugrec]

Hi,
I'm getting segfaults when working with MIDI tracks. I don't have perfectly repeatable steps to trigger the crash, but I can get it to happen under gdb.

Typical session leading to a crash :

• add MIDI track, add plugin (e.g. General MIDI), play a bit with USB-MIDI controller. Close dialog
• add another MIDI track, add plugin (e.g. Red Zeppelin drumkit), play a bit with controller, close dialog

Backtrace seems to indicate the segfault happens in the gmsynth.lv2 plugin I was using, but unclear if the root cause is the plugin or something that qtractor does ? (I notice I don't have debug symbols for qtractor... shame)

Thread 1 "qtractor" received signal SIGSEGV, Segmentation fault.
0x00007ffff60cea2b in ?? () from /usr/lib/libc.so.6
(gdb) i s
#0  0x00007ffff60cea2b in ?? () from /usr/lib/libc.so.6
#1  0x00007ffff5cafa3e in g_str_equal (v1=<optimized out>, v2=<optimized out>) at ../glib/glib/ghash.c:2433
#2  0x00007ffff5cb07a3 in g_hash_table_lookup_node (hash_table=0x555555a392a0, key=0x7fffbee86add,
    hash_return=<synthetic pointer>) at ../glib/glib/ghash.c:437
#3  g_hash_table_lookup (hash_table=0x555555a392a0, key=0x7fffbee86add) at ../glib/glib/ghash.c:1483
#4  0x00007ffff5cdb7d1 in quark_from_string (string=0x7fffbee86add "IpatchBase", duplicate=0x0)
    at ../glib/glib/gquark.c:182
#5  quark_intern_string_locked (string=0x7fffbee86add "IpatchBase", duplicate=0x0) at ../glib/glib/gquark.c:322
#6  g_intern_static_string (string=0x7fffbee86add "IpatchBase") at ../glib/glib/gquark.c:371
#7  0x00007fffbee2d58e in ?? () from /usr/lib/libinstpatch-1.0.so.2
#8  0x00007fffbee2d615 in ipatch_base_get_type () from /usr/lib/libinstpatch-1.0.so.2
#9  0x00007fffbee848f1 in ipatch_init () from /usr/lib/libinstpatch-1.0.so.2
#10 0x00007fffbef1e097 in new_fluid_synth () from /usr/lib/libfluidsynth.so.3
#11 0x00007fffe000b51b in ?? () from /usr/lib/lv2/gmsynth.lv2/gmsynth.so
#12 0x00007ffff64fd97c in lilv_plugin_instantiate (plugin=0x555557404da0, sample_rate=48000, features=<optimized out>)
    at ../lilv-0.24.24/src/instance.c:63
#13 0x00005555556b91f5 in ?? ()
#14 0x000055555575b6d4 in ?? ()
#15 0x000055555575cfcf in ?? ()
#16 0x00005555557a0724 in ?? ()
#17 0x000055555578bf3b in ?? ()
#18 0x000055555581ab4b in ?? ()
#19 0x000055555581c10b in ?? ()
#20 0x00005555558218a6 in ?? ()
#21 0x00007ffff6b7b94a in doActivate<false> (sender=<optimized out>, signal_index=<optimized out>,
    argv=<optimized out>) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobject.cpp:4098
#22 0x00007ffff74f5264 in QAction::triggered (this=<optimized out>, _t1=<optimized out>)
    at /usr/src/debug/qt6-base/build/src/gui/Gui_autogen/include/moc_qaction.cpp:480
#23 QAction::activate (this=0x55555610bb60, event=<optimized out>)
    at /usr/src/debug/qt6-base/qtbase/src/gui/kernel/qaction.cpp:1102

Build provided by distro (arch linux).

[rncbc]

latest gmsynth.lv2 includes its own copy of (lib)fluidsynth, statically linked.

dunno why the arch version still dynamically links to system libfluidsynth.so, which links to libinstpatch.so in turn and ultimately to glib.so which is probably the root cause of your problems.

[fenugrec]

thanks for looking at this. Not sure I'll be able to dig further; I wasn't able to reproduce the problem with other software (carla, ardour).

[rncbc]

the gmsynth.lv2 package from archlinux.org is really something: it explicitly patches the x42's upstream source code to exclude the bundled fluidsynth static code in favor to system shared libraries... (can't argue with that it's a arch's packager call for x-sake)

just build the plugin from source (https://github.com/x42/gmsynth.lv2) and you can confirm for yourself...

besides, v1.0.0 is not the current recommendation anymore, go with v1.1.1 at least.