MIDI Transpose crashes Ardour when last instance is removed from the session

[DanijelMilosevic]

MIDI Transpose (unlike MIDI Chromatic Transpose or MIDI Key Transpose) crashes Ardour when the last instance of it is removed from the session, or when closing the session, or Ardour itself:

lilv_world_load_bundle(): note: Newer version of http://gareus.org/oss/lv2/midifilter#cctonote loaded from file:///home/motka/.lv2/midifilter.lv2/ GLib (gthread-posix.c): Unexpected error from C library during 'pthread_setspecific': Invalid argument. Aborting. Aborted (core dumped)

I tested with the version that is in the current debian repositories (5:20210114), as well as the latest x42-midifilter-v0.7.3-x86_64.tar.gz. On the Ardour side, I tested with Ardour 8.10, as well as ardour8-lua (the Lua Console "Headless" version)

Steps to reproduce:

1. make new Ardour session
2. make a new empty MIDI track
3. insert MIDI Transpose
4. remove MIDI Transpose
5. ---> CRASH

Workaround: use MIDI Chromatic Transpose

I was not sure where to report this, since it is installed with x42 midifilter package, but the author is Filipe Coelho :) Thanks!

[falkTX]

there is no ardour on the kxstudio repos since a few years now...

[DanijelMilosevic]

Thanks! I thought this could be the plugin bug. Should I report this to the Ardour team?

[falkTX]

hard to say where the bug is, but well its the same person doing the support for both lv2 plugin and host side so we can just ping @x42 here

[falkTX]

actually I think this "MIDI Transpose" is the one exposed from Carla. but the error you get is not something that any carla plugin code uses

[DanijelMilosevic]

Thank you! Not sure what "exposed from Carla" means, but here is the info from Ardours plugin scan:

URI: http://kxstudio.sf.net/carla/plugins/miditranspose Bundle: file:///usr/lib/lv2/carla.lv2/ LV2 Category: 'Utility Plugin' LV2 Parent Class URI: 'http://lv2plug.in/ns/lv2core#Plugin' LV2 Ports: Atom-in: 1, Atom-out: 1, Audio-in: 0 Audio-out: 0 MIDI-in: 1 MIDI-out: 1 Ctrl-in: 3 Ctrl-out: 0

[x42]

GLib (gthread-posix.c): Unexpected error from C library during 'pthread_setspecific': Invalid argument. Aborting.

That is weird. the x42 midi plugin does not use any threads. Maybe it's falktx' plugin (carla.lv2) after all?

In any case, I cannot reproduce the crash. I can add/remove all 3 of those plugins just fine in Ardour 8.10.0 (from ardour.org).

So we will need more information about this. Ideally could you get a backtrace of the crash? The long story how to do this is described at https://ardour.org/debugging_ardour in short

open a Terminal window, run Ardour8 --gdb on the gdb prompt: run (and press enter) then when ardour crashes, go back to the terminal and type thread apply all bt (and press enter). This will produce several pages of text which may help to pinpoint the issue.

[DanijelMilosevic]

Thanks for the debugging instructions link! I wasn't aware one can get nightly builds, so I got one today, and I could reproduce the crash with it as well, using the same steps from my original post. I attached the gdb outputs from:

Ardour-8.10.0 running ALSA Ardour-8.10.0 running JACK Ardour-9.0.pre0.439_dbg running DUMMY

The plugin that crashes my Ardour shows up in the plugin list like the third plugin in your screenshot (MIDI Transpose -- plugin utility -- Filipe Coelho - LV2)

Please let me know if I can help further, and thanks for your work!

gdb_output_Ardour_9.0.pre0.439_dbg_dummy.txt gdb_output_Ardour8.10_jack.txt gdb_output_Ardour8.10_alsa.txt

[x42]

Thanks. You're close, yet you've skipped the last step: get the actual backtrace

after the crash at the gdb prompt type bt (and press enter).

[DanijelMilosevic]

ohhhh sorry, I knew it was a bad idea to do this after a 35-hour bus ride :) Here are the actual backtraces:

gdb_bt_Ardour_9.0.pre0.439_dbg_dummy.txt gdb_bt_Ardour8.10_jack.txt gdb_bt_Ardour8.10_alsa.txt

[x42]

@falkTX does your plugin set thread-local variables?

[falkTX]

I dont recall ever using such things for carla. but since the lv2 binary includes part of carla there might be some static initialization things in there.

[x42]

@falkTX last I ran into an issue like this was with abique's u-he/Linux plugins

They do set thread-keys, free the data stored there, but not unset the key. This leads to a double-free in __nptl_deallocate_tsd nptl/pthread_create.c:175 __pthread_keys[idx].destr (data); when the event-loop thread is joined. I guess openssl related.

Then again

GLib (gthread-posix.c): Unexpected error from C library during 'pthread_setspecific': Invalid argument.

could be caused by static initialization of pthread as well: https://stackoverflow.com/questions/30491839/pthread-library-fails-when-called-from-static-constructor-code