View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0008427ardourbugspublic2020-09-28 16:232020-09-28 20:28
Reporterventosus Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionno change required 
PlatformArchOSLinuxOS Version(any)
Product Version6.3 
Summary0008427: crash upon LV2 plugin closure due to SIGINT (destined for UI child process) interception by gtk? (OMK plugins)
DescriptionHi

Some of my code-based LV2 plugin UIs use an embedded terminal emulator which can run the users console editor of choice (vim, emacs, nano, etc.).

Since recently (ardour 6+ I think, not sure when exactly), those UIs crash Ardour upon closure.

Dump attached.

The problem as I see it is: upon closure, the UI sends a SIGINT to the child process to close it (e.g. vim, emacs, ...).

Ardour and/or GTK seem to intercept that signal and try do do something with it and crashes.

Other hosts (jalv, carla, qtractor, synthpod) work just fine, Ardour is the only one showing this issue.
Steps To Reproducehttps://git.open-music-kontrollers.ch/lv2/notes.lv2 is the simplest plugin showing the crash.
TagsNo tags attached.

Activities

ventosus

2020-09-28 16:23

reporter  

dump.txt (1,932 bytes)    
(gdb) bt full
#0  0x00007ffff4cd74ed in getenv () at /usr/lib/libc.so.6
#1  0x00007ffff717728d in ArdourCanvas::Canvas::render(ArdourCanvas::Rect const&, Cairo::RefPtr<Cairo::Context> const&) const () at /usr/lib/ardour6/libcanvas.so.0
#2  0x00007ffff7177611 in ArdourCanvas::GtkCanvas::on_expose_event(_GdkEventExpose*) () at /usr/lib/ardour6/libcanvas.so.0
#3  0x00007ffff5fb1098 in Gtk::Widget_Class::expose_event_callback(_GtkWidget*, _GdkEventExpose*) () at /usr/lib/libgtkmm-2.4.so.1
#4  0x00007ffff680803c in  () at /usr/lib/libgtk-x11-2.0.so.0
#5  0x00007ffff6c71052 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
#6  0x00007ffff6c993d0 in  () at /usr/lib/libgobject-2.0.so.0
#7  0x00007ffff6c8cbab in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
#8  0x00007ffff6c8dae0 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
#9  0x00007ffff69246f8 in  () at /usr/lib/libgtk-x11-2.0.so.0
#10 0x00007ffff6806e11 in gtk_main_do_event () at /usr/lib/libgtk-x11-2.0.so.0
#11 0x00007ffff6661a90 in  () at /usr/lib/libgdk-x11-2.0.so.0
#12 0x00007ffff6661a33 in  () at /usr/lib/libgdk-x11-2.0.so.0
#13 0x00007ffff6661a33 in  () at /usr/lib/libgdk-x11-2.0.so.0
#14 0x00007ffff6661a33 in  () at /usr/lib/libgdk-x11-2.0.so.0
#15 0x00007ffff665e4cf in  () at /usr/lib/libgdk-x11-2.0.so.0
#16 0x00007ffff665ee20 in gdk_window_process_all_updates () at /usr/lib/libgdk-x11-2.0.so.0
#17 0x00007ffff665ee79 in  () at /usr/lib/libgdk-x11-2.0.so.0
#18 0x00007ffff663d257 in  () at /usr/lib/libgdk-x11-2.0.so.0
#19 0x00007ffff6b80b00 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#20 0x00007ffff6bd21f9 in  () at /usr/lib/libglib-2.0.so.0
#21 0x00007ffff6b80163 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#22 0x00007ffff6805b7e in gtk_main () at /usr/lib/libgtk-x11-2.0.so.0
#23 0x00007ffff6ff5ff9 in Gtkmm2ext::UI::run(Receiver&) () at /usr/lib/ardour6/libgtkmm2ext.so.0
#24 0x00005555559f8286 in main ()
dump.txt (1,932 bytes)   

x42

2020-09-28 17:25

administrator   ~0025073

I do not recall any changes as to why this would have worked in the past.
The backtrace shows g_signal_emit` which is for GTK/GDK events, unrelated to ANSI C signal handling.
The only signal handler that ardour installs itself is SIGPIPE.

ventosus

2020-09-28 20:18

reporter   ~0025077

thanks, this somehow put me on the right track, indeed seems not to be the signal's fault.

The culprit is in the plugin's UI:

    putenv("TERM=xterm-256color");

This obviously confuses glib - hence the crash in its getenv.

I can solve that differently, thanks a lot.

x42

2020-09-28 20:28

administrator   ~0025078

if you vfork the child process, you should be able to set the new in environment in execve(), leaving the host's env alone.
You may also benefit from resetting the whole environment to not inherit ardour's LD_LIBRARY_PATH.

Issue History

Date Modified Username Field Change
2020-09-28 16:23 ventosus New Issue
2020-09-28 16:23 ventosus File Added: dump.txt
2020-09-28 17:25 x42 Note Added: 0025073
2020-09-28 20:18 ventosus Note Added: 0025077
2020-09-28 20:19 ventosus Status new => closed
2020-09-28 20:19 ventosus Resolution open => no change required
2020-09-28 20:28 x42 Note Added: 0025078