#211 Qtractor crash with whysynth-dssi when loading a patch bank

[Holger Marzen]

It works fine with Qtractor 0.7.6

In later versions, e.g. 2016-04-23, there seems to be a bug was introduced that leads to errors with dssi-plugins:

• whysynth-dssi: Qtractor crashes when I try to load a patch bank
• fluidsynth-dssi: Qtractor crashes when I try to load a soundfont

It might be related to liblo, i.e. sending messages. I installed the most recent liblo, recompiled whysynth and Qtractor git head, no change. Qtractor 0.7.6 works fine.

[Rui Nuno Capela]

been trying to reproduce the crashes to no avail; seems to work fine, no crashes, with both fluidsynth-dssi and whysynth-dssi;

versions used:

whysynth: 20120903
fluidsynth-dssi: 1.0.0 (+cleanup patch)
fluidsynth: 1.1.6
liblo: 0.28
dssi: 1.1.1
qtractor: 0.7.7.17 (current git head)
qt: 5.6.0

please, try to get a debug build to crash and catch a stacktrace on the spot.

byee

[Holger Marzen]

Maybe a qt4 thing? I started Qtractor in gdb. Is that the same thing as building a debug version of Qtractor?

Starting program: /usr/local/bin/qtractor 
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe55dc700 (LWP 6941)]
[New Thread 0x7fffe4ddb700 (LWP 6942)]
[New Thread 0x7fffdd6b0700 (LWP 6943)]
[New Thread 0x7fffdd62f700 (LWP 6944)]
[New Thread 0x7fffdcab8700 (LWP 6945)]
[New Thread 0x7fffdd5ae700 (LWP 6946)]
[New Thread 0x7fffd1c9f700 (LWP 6947)]
[New Thread 0x7fffd149e700 (LWP 6948)]
[New Thread 0x7fffd0c9d700 (LWP 6949)]
[New Thread 0x7fffb9dbd700 (LWP 6954)]
[New Thread 0x7fffb95bc700 (LWP 6955)]
[New Thread 0x7fffb8dbb700 (LWP 6956)]
[Thread 0x7fffe55dc700 (LWP 6941) exited]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffb95bc700 (LWP 6955)]
0x00007ffff4b31d2c in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
(gdb) bt
#0  0x00007ffff4b31d2c in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#1  0x00007ffff4b33a66 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#2  0x00007ffff4b33efd in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#3  0x00007ffff4ac0fd2 in QInternalMimeData::formats() const ()
   from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#4  0x00007ffff4b31aa6 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#5  0x00007ffff4ac1154 in QInternalMimeData::hasFormat(QString const&) const ()
   from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#6  0x00007ffff45994e8 in QMimeData::hasUrls() const ()
   from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#7  0x00000000005c0bee in ?? ()
#8  0x00000000005c2988 in ?? ()
#9  0x0000000000475c27 in ?? ()
#10 0x00007ffff61665a1 in dispatch_method () from /usr/local/lib/liblo.so.7
#11 0x00007ffff6168b74 in dispatch_data () from /usr/local/lib/liblo.so.7
#12 0x00007ffff6168f2d in lo_server_recv () from /usr/local/lib/liblo.so.7
#13 0x00007ffff616a18d in thread_func () from /usr/local/lib/liblo.so.7
#14 0x00007ffff41fae9a in start_thread (arg=0x7fffb95bc700) at pthread_create.c:308
#15 0x00007ffff370336d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#16 0x0000000000000000 in ?? ()
(gdb) 

[Rui Nuno Capela]

I started Qtractor in gdb. Is that the same thing as building a debug version of Qtractor?

not quite: a debug build is done by ./configure --enable-debug ...

running under gdb might show something but without proper debug symbols like function names, source line numbers of stack frames, etc. instead of the above "in ?? ()" you see up there.

anyway, it probably is a dang old qt4 thing; liblo seems to mess with the application clipboard somehow...

[Holger Marzen]

I attach the output produced by Qtractor configured with

./configure --enable-qt4 --enable-lv2-event --enable-debug --enable-stacktrace

[Rui Nuno Capela]

please, consider taking yet more evidences or crash stacktraces--see if they all point or involve to the same spot.

reading from this and the earlier backtrace, my suspicions goes like that QMimeData::hasUrls() and QInternalMimeData::hasFormat(QString const&) do appear in both situations and thus common at stake here.

seeya

[Holger Marzen]

I can reproduce the same crash with fluidsynth-dssi.

osc_configure: path "/dssi/FluidSynth-DSSI.6b8f780", key "load", value "/home/hm/soundfonts/gm/FluidR3_GM_hm.sf2"
qtractorDssiPlugin[0x6b8f780]::configure("load", "/home/hm/soundfonts/gm/FluidR3_GM_hm.sf2")
[xcb] Unknown request in queue while dequeuing
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
qtractor: ../../src/xcb_io.c:179: dequeue_pending_request: Zusicherung »!xcb_xlib_unknown_req_in_deq« nicht erfüllt.

So maybe this isn't a liblo thing but something with changed thread- and X-handling? Maybe in qtractorDssiPlugin.cpp ?

[Rui Nuno Capela]

aand yet there are again QMimeData::hasUrls() and QInternalMimeData::hasFormat(QString const&) in the vacinity:

#14 0x00007fc199bed154 in QInternalMimeData::hasFormat(QString const&) const () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#15 0x00007fc1996c54e8 in QMimeData::hasUrls() const () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4

just a far fetched hunch but could it be a gcc5/6 ABI issue?

nevertheless i'll try to mitigate this on qt4 builds; bbl.

ps. done. try this git head master [041a77] aka. qtractor 0.7.7.18+