closing Vitalium LV2 plugin GUI crashes Ardour

[Be-ing]

Thread 41 "ArdourGUI" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff7c7b4640 (LWP 30198)]
0x00007ffff545ccd4 in __dynamic_cast () from /lib64/libstdc++.so.6
(gdb) bt
#0  0x00007ffff545ccd4 in __dynamic_cast () at /lib64/libstdc++.so.6
#1  0x00007fff7cce8db6 in juce::XWindowSystem::windowMessageReceive(_XEvent&) (event=...)
    at ../libs/juce-current/source/modules/juce_gui_basics/native/x11/juce_linux_XWindowSystem.cpp:3680
#2  0x00007fff7cce671c in operator()(int) const (__closure=0x7fff74000c80) at ../libs/juce-current/source/modules/juce_gui_basics/native/x11/juce_linux_XWindowSystem.cpp:3046
#3  0x00007fff7ccf573a in std::__invoke_impl<void, juce::XWindowSystem::initialiseXDisplay()::<lambda(int)>&, int>(std::__invoke_other, struct {...} &) (__f=...)
    at /usr/include/c++/10/bits/invoke.h:60
#4  0x00007fff7ccf1bff in std::__invoke_r<void, juce::XWindowSystem::initialiseXDisplay()::<lambda(int)>&, int>(struct {...} &) (__fn=...) at /usr/include/c++/10/bits/invoke.h:153
#5  0x00007fff7cceec11 in std::_Function_handler<void(int), juce::XWindowSystem::initialiseXDisplay()::<lambda(int)> >::_M_invoke(const std::_Any_data &, int &&)
    (__functor=..., __args#0=@0x7fff7c7b38c4: 61) at /usr/include/c++/10/bits/std_function.h:291
#6  0x00007fff7cb42ed4 in std::function<void (int)>::operator()(int) const (this=0x7fff74000c80, __args#0=61) at /usr/include/c++/10/bits/std_function.h:622
#7  0x00007fff7cb3f0a9 in juce::InternalRunLoop::dispatchPendingEvents() (this=0x7fff74000bd0) at ../libs/juce-current/source/modules/juce_events/native/juce_linux_Messaging.cpp:186
#8  0x00007fff7cb3a071 in juce::MessageManager::dispatchNextMessageOnSystemQueue(bool) (returnIfNoPendingMessages=false)
    at ../libs/juce-current/source/modules/juce_events/native/juce_linux_Messaging.cpp:300
#9  0x00007fff7cb34df3 in juce::MessageManager::runDispatchLoop() (this=0x7fff74000ba0) at ../libs/juce-current/source/modules/juce_events/messages/juce_MessageManager.cpp:128
#10 0x00007fff7c9a807d in SharedMessageThread::run() (this=0x555558045e00) at ../libs/juce-current/source/modules/juce_audio_plugin_client/LV2/juce_LV2_Wrapper.cpp:160
#11 0x00007fff7caa5716 in juce::Thread::threadEntryPoint() (this=0x555558045e00) at ../libs/juce-current/source/modules/juce_core/threads/juce_Thread.cpp:96
#12 0x00007fff7caa57d5 in juce::juce_threadEntryPoint(void*) (userData=0x555558045e00) at ../libs/juce-current/source/modules/juce_core/threads/juce_Thread.cpp:118
#13 0x00007fff7cac65bd in juce::threadEntryProc(void*) (userData=0x555558045e00) at ../libs/juce-current/source/modules/juce_core/native/juce_posix_SharedCode.h:877
#14 0x00007ffff5b633f9 in start_thread () at /lib64/libpthread.so.0
#15 0x00007ffff5187903 in clone () at /lib64/libc.so.6
(gdb) f 1
#1  0x00007fff7cce8db6 in juce::XWindowSystem::windowMessageReceive (event=...) at ../libs/juce-current/source/modules/juce_gui_basics/native/x11/juce_linux_XWindowSystem.cpp:3680
3680                if (auto* peer = dynamic_cast<LinuxComponentPeer*> (getPeerFor (event.xany.window)))
(gdb) info arg
event = @0x7fff7c7b3740: {type = 18, xany = {type = 18, serial = 15827, send_event = 0, display = 0x7fff74001720, window = 127926287}, xkey = {type = 18, serial = 15827, send_event = 0, 
    display = 0x7fff74001720, window = 127926287, root = 127926287, subwindow = 0, time = 4869343, x = 1424, y = -4, x_root = 2677, y_root = 564, state = 0, keycode = 1, same_screen = 1}, 
  xbutton = {type = 18, serial = 15827, send_event = 0, display = 0x7fff74001720, window = 127926287, root = 127926287, subwindow = 0, time = 4869343, x = 1424, y = -4, x_root = 2677, 
    y_root = 564, state = 0, button = 1, same_screen = 1}, xmotion = {type = 18, serial = 15827, send_event = 0, display = 0x7fff74001720, window = 127926287, root = 127926287, 
    subwindow = 0, time = 4869343, x = 1424, y = -4, x_root = 2677, y_root = 564, state = 0, is_hint = 1 '\001', same_screen = 1}, xcrossing = {type = 18, serial = 15827, send_event = 0, 
    display = 0x7fff74001720, window = 127926287, root = 127926287, subwindow = 0, time = 4869343, x = 1424, y = -4, x_root = 2677, y_root = 564, mode = 0, detail = 1, same_screen = 1, 
    focus = 1, state = 0}, xfocus = {type = 18, serial = 15827, send_event = 0, display = 0x7fff74001720, window = 127926287, mode = 127926287, detail = 0}, xexpose = {type = 18, 
    serial = 15827, send_event = 0, display = 0x7fff74001720, window = 127926287, x = 127926287, y = 0, width = 0, height = 0, count = 4869343}, xgraphicsexpose = {type = 18, 
    serial = 15827, send_event = 0, display = 0x7fff74001720, drawable = 127926287, x = 127926287, y = 0, width = 0, height = 0, count = 4869343, major_code = 0, minor_code = 1424}, 
  xnoexpose = {type = 18, serial = 15827, send_event = 0, display = 0x7fff74001720, drawable = 127926287, major_code = 127926287, minor_code = 0}, xvisibility = {type = 18, 
    serial = 15827, send_event = 0, display = 0x7fff74001720, window = 127926287, state = 127926287}, xcreatewindow = {type = 18, serial = 15827, send_event = 0, display = 0x7fff74001720, 
    parent = 127926287, window = 127926287, x = 0, y = 0, width = 4869343, height = 0, border_width = 1424, override_redirect = -4}, xdestroywindow = {type = 18, serial = 15827, 
    send_event = 0, display = 0x7fff74001720, event = 127926287, window = 127926287}, xunmap = {type = 18, serial = 15827, send_event = 0, display = 0x7fff74001720, event = 127926287, 
    window = 127926287, from_configure = 0}, xmap = {type = 18, serial = 15827, send_event = 0, display = 0x7fff74001720, event = 127926287, window = 127926287, override_redirect = 0}, 
  xmaprequest = {type = 18, serial = 15827, send_event = 0, display = 0x7fff74001720, parent = 127926287, window = 127926287}, xreparent = {type = 18, serial = 15827, send_event = 0, 
    display = 0x7fff74001720, event = 127926287, window = 127926287, parent = 0, x = 4869343, y = 0, override_redirect = 1424}, xconfigure = {type = 18, serial = 15827, send_event = 0, 
    display = 0x7fff74001720, event = 127926287, window = 127926287, x = 0, y = 0, width = 4869343, height = 0, border_width = 1424, above = 2422361557621, override_redirect = 0}, 
  xgravity = {type = 18, serial = 15827, send_event = 0, display = 0x7fff74001720, event = 127926287, window = 127926287, x = 0, y = 0}, xresizerequest = {type = 18, serial = 15827, 
    send_event = 0, display = 0x7fff74001720, window = 127926287, width = 127926287, height = 0}, xconfigurerequest = {type = 18, serial = 15827, send_event = 0, display = 0x7fff74001720, 
    parent = 127926287, window = 127926287, x = 0, y = 0, width = 4869343, height = 0, border_width = 1424, above = 2422361557621, detail = 0, value_mask = 4294967297}, xcirculate = {
    type = 18, serial = 15827, send_event = 0, display = 0x7fff74001720, event = 127926287, window = 127926287, place = 0}, xcirculaterequest = {type = 18, serial = 15827, send_event = 0, 
    display = 0x7fff74001720, parent = 127926287, window = 127926287, place = 0}, xproperty = {type = 18, serial = 15827, send_event = 0, display = 0x7fff74001720, window = 127926287, 
    atom = 127926287, time = 0, state = 4869343}, xselectionclear = {type = 18, serial = 15827, send_event = 0, display = 0x7fff74001720, window = 127926287, selection = 127926287, 
    time = 0}, xselectionrequest = {type = 18, serial = 15827, send_event = 0, display = 0x7fff74001720, owner = 127926287, requestor = 127926287, selection = 0, target = 4869343, 
    property = 18446744056529683856, time = 2422361557621}, xselection = {type = 18, serial = 15827, send_event = 0, display = 0x7fff74001720, requestor = 127926287, 
    selection = 127926287, target = 0, property = 4869343, time = 18446744056529683856}, xcolormap = {type = 18, serial = 15827, send_event = 0, display = 0x7fff74001720, 
    window = 127926287, colormap = 127926287, c_new = 0, state = 0}, xclient = {type = 18, serial = 15827, send_event = 0, display = 0x7fff74001720, window = 127926287, 
    message_type = 127926287, format = 0, data = {b = "\337LJ\000\000\000\000\000\220\005\000\000\374\377\377\377u\n\000", s = {19679, 74, 0, 0, 1424, 0, -4, -1, 2677, 0}, l = {4869343, 
        -17179867760, 2422361557621, 4294967296, 4294967297}}}, xmapping = {type = 18, serial = 15827, send_event = 0, display = 0x7fff74001720, window = 127926287, request = 127926287, 
    first_keycode = 0, count = 0}, xerror = {type = 18, display = 0x3dd3, resourceid = 0, serial = 140735139551008, error_code = 15 '\017', request_code = 0 '\000', 
    minor_code = 160 '\240'}, xkeymap = {type = 18, serial = 15827, send_event = 0, display = 0x7fff74001720, window = 127926287, 
    key_vector = "\017\000\240\a", '\000' <repeats 12 times>, "\337LJ\000\000\000\000\000\220\005\000\000\374\377\377\377"}, xgeneric = {type = 18, serial = 15827, send_event = 0, 
    display = 0x7fff74001720, extension = 127926287, evtype = 0}, xcookie = {type = 18, serial = 15827, send_event = 0, display = 0x7fff74001720, extension = 127926287, evtype = 0, 
    cookie = 127926287, data = 0x0}, pad = {140733193388050, 15827, 0, 140735139551008, 127926287, 127926287, 0, 4869343, -17179867760, 2422361557621, 4294967296, 4294967297, 0, 255, 
    34359738624, 140735139617648, 1009, 140735139545216, 140735139545216, 16711680, 65280, 255, 34359738624, 140735139617704}}
(gdb) info local
peer = 0x7fff7ccde396 <juce::XWindowSystemUtilities::ScopedXLock::~ScopedXLock()+72>
instance = 0x7fff7c7b3720

[falkTX]

oh I know, I am investigating this now.

[falkTX]

I have an ugly workaround. It works, but damn ugly. I think JUCE is doing something wrong with X11 and pointers, leading to somehow the same pointer being stored in multiple places. Issue does is not triggered under normal circumstances, but happens if adding and removing from "desktop" like lv2 does. At some point we need to redo the LV2 UI stuff on JUCE, but my motivation for JUCE related things is always lacking, it is such a huge bloated codebase...

Anyway, look away. Fix works, which is all we care about right?

[Be-ing]

Does JUCE have a public bug tracker? At least we could report the issue upstream and hope they come up with a better solution. If they don't have a public bug tracker, then :shrug:

[falkTX]

Issue does not happen with regular vst or vst3, so I doubt they care.

[Tremeschin]

Issue does not happen with regular vst or vst3, so I doubt they care.

Just saying my (entire) feedback here instead of opening new issue since it's half related

Both Vital and Vitalium LV2 are acting very weird for me, however taylordotfish's fork the Vial LV2 runs surprisingly well here (though he applied quite some patches). The others both in Ardour or Carla when I open / close the window it renders some foreground elements black and the background image is weirdly offsetted, then crashes.

(Also Vitalium LV2 entire UI is wrongly offsetted, it starts on the window decorator top left instead of the window viewport, can be GNOME or some theme I'm using, though heard some people reporting this happening on openbox, not a single place this doesn't happen for me, Carla, Ardour, jalv.gtk)

I've been using Vital LXVST2 version up until now, it's the only one that works without weird issues on Linux but looks like the rendering process doesn't get stopped when we close the GUI, so more instances = less responsiveness (because more GPU work? though with mangohud they are limited properly to vsync at least on AMD GPU, can't confirm this). The VST3 version (at least Vital) was quite unstable when I closed one instance and opened another, though this was an older version I think (which the source code should be).

One more question than opening new issue, is there anything we can do regarding memory usage of Vitalium? each instance uses about 300 MB and that escalates quite a lot, poor me with only 8 GB RAM.. Don't know enough C++ to tell if this is a bunch of static libs being loaded instead of shared ones across instances, nor if this is how it works, or if it is the plugin not entering some "minimal headless standby" mode, if you could explain the implications or if it's even solvable at first I'll be thankful.

[mitchmindtree]

Just wanted to mention I'm still running into this on master https://github.com/DISTRHO/DISTRHO-Ports/commit/67cdebbd2472380ac5c4339ac82fba4749b0e6da, built with the same approach mentioned here. Let me know if there are any debug flags, env var output or logs I can provide if you're curious to dig deeper.

[falkTX]

I am waiting for Matt to publish his custom juce changes, so we can apply potential fixes. https://github.com/mtytel/vital/issues/16

btw the LV2 seems more unstable compared to VST2 or VST3.

[falkTX]

I waited some days, went and did a manual diff instead now. The distrho juce code is updated, now includes vital-side changes, please test. thanks.

I am updating the kxstudio repo packages now too.

[mitchmindtree]

Behaviour of LV2 plugin in Ardour on https://github.com/DISTRHO/DISTRHO-Ports/commit/18ff140a96c133799c1c178a38a84ce6e1c523be appears to be the same for me - still crashes when closing window, still has vertical input offset.

For the record, the same issues apply to the official Vital binary version (at least when I checked a couple of days ago) so maybe issues for these are better off at the Vital repo anyways? Not sure if I can personally report there though as I'm running NixOS (not a Debian variant) and use a tool to automatically patch the ELF file.

[falkTX]

Matt (Vital author) has mention he will not merge pull-requests, so we trying to fix anything in there is pointless.

It is somewhat good if the same issue happens with the original. At the moment I am mainly concerned about not having issues that the original one does. Once we are on-par stability-wise, we reached a good point to try to do some fixes ourselves in this repo.

[falkTX]

@mitchmindtree can you install an ardour debug build and build vitalium in debug mode, in order to try and get some more info on this? I was able to reproduce the original issue and fixed it, yours might be something else.

on plugin side, what you need for this repo is:

meson build --buildtype debug -Dplugins=vitalium

[falkTX]

@Be-ing likely fixed in latest commit, please verify, thanks!

[Be-ing]

Now the window closes without crashing, but reopening the GUI crashes:

JUCE Assertion failure in juce_OpenGLShaderProgram.cpp:138

Thread 46 "Pool" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff6affd640 (LWP 533977)]
juce::OpenGLShaderProgram::use (this=0x7fff5c60af00) at ../libs/juce-current/source/modules/juce_opengl/opengl/juce_OpenGLShaderProgram.cpp:140
140         context.extensions.glUseProgram (programID);
(gdb) bt
#0  juce::OpenGLShaderProgram::use() const (this=0x7fff5c60af00) at ../libs/juce-current/source/modules/juce_opengl/opengl/juce_OpenGLShaderProgram.cpp:140
#1  0x00007fff7ed45783 in OpenGlMultiQuad::render(OpenGlWrapper&, bool) (this=0x55556291a0e8, open_gl=..., animate=true)
    at ../ports/vitalium/source/interface/editor_components/open_gl_multi_quad.cpp:143
#2  0x00007fff7ed552a6 in MidiKeyboard::render(OpenGlWrapper&, bool) (this=0x555562919a30, open_gl=..., animate=true)
    at ../ports/vitalium/source/interface/editor_components/midi_keyboard.cpp:188
#3  0x00007fff7edac86a in SynthSection::renderOpenGlComponents(OpenGlWrapper&, bool) (this=0x555562332ee0, open_gl=..., animate=true)
    at ../ports/vitalium/source/interface/editor_sections/synth_section.cpp:381
#4  0x00007fff7edac792 in SynthSection::renderOpenGlComponents(OpenGlWrapper&, bool) (this=0x555559eeb7e0, open_gl=..., animate=true)
    at ../ports/vitalium/source/interface/editor_sections/synth_section.cpp:376
#5  0x00007fff7ec0d589 in FullInterface::renderOpenGL() (this=0x555559eeb7e0) at ../ports/vitalium/source/interface/editor_sections/full_interface.cpp:562
#6  0x00007fff7ef65d35 in juce::OpenGLContext::CachedImage::renderFrame() (this=0x55556284a310) at ../libs/juce-current/source/modules/juce_opengl/opengl/juce_OpenGLContext.cpp:255
#7  0x00007fff7ef6660c in juce::OpenGLContext::CachedImage::runJob() (this=0x55556284a310) at ../libs/juce-current/source/modules/juce_opengl/opengl/juce_OpenGLContext.cpp:486
#8  0x00007fff7e2a761e in juce::ThreadPool::runNextJob(juce::ThreadPool::ThreadPoolThread&) (this=0x55555afc9510, thread=...)
    at ../libs/juce-current/source/modules/juce_core/threads/juce_ThreadPool.cpp:384
#9  0x00007fff7e2dc0bb in juce::ThreadPool::ThreadPoolThread::run() (this=0x5555661c1aa0) at ../libs/juce-current/source/modules/juce_core/threads/juce_ThreadPool.cpp:36
#10 0x00007fff7e2a5918 in juce::Thread::threadEntryPoint() (this=0x5555661c1aa0) at ../libs/juce-current/source/modules/juce_core/threads/juce_Thread.cpp:96
#11 0x00007fff7e2a59d7 in juce::juce_threadEntryPoint(void*) (userData=0x5555661c1aa0) at ../libs/juce-current/source/modules/juce_core/threads/juce_Thread.cpp:118
#12 0x00007fff7e2c67bf in juce::threadEntryProc(void*) (userData=0x5555661c1aa0) at ../libs/juce-current/source/modules/juce_core/native/juce_posix_SharedCode.h:877
#13 0x00007ffff5b603f9 in start_thread () at /lib64/libpthread.so.0
#14 0x00007ffff5184b53 in clone () at /lib64/libc.so.6

[falkTX]

what plugin format is this? does it happen with all of them?

[mitchmindtree]

Just wanted to mention that Vitalium is working nicely for me now! Must have been one or more of the commits in the last week or two, though I'm uncertain which.

To clarify, on the current master, both the GUI view offset is fixed and ardour no longer crashes when closing/opening the plugin window :) I've only tested with LV2.

[Tremeschin]

Just wanted to mention that Vitalium is working nicely for me now! Must have been one or more of the commits in the last week or two, though I'm uncertain which.

To clarify, on the current master, both the GUI view offset is fixed and ardour no longer crashes when closing/opening the plugin window :) I've only tested with LV2.

Hello just tried here distrho-ports-lv2-git from AUR and can confirm, feels like Vitalium is working nicely without GUI offsets and closing / opening on Carla doesn't yields cursed interface, working on Ardour as well.

Will take the risk and sketch new projects with it, hopefully no major issues!

[kmatheussen]

The Vitalium VST2 plugin crashes in Radium when closing the GUI. It's inside 'dynamic_cast' here as well so I guess it's the same bug:

Thread 18 "radium_linux.bi" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff643e9700 (LWP 5794)]
__cxxabiv1::__dynamic_cast (src_ptr=0x610001179740, src_type=0x7fff65c963d8 <typeinfo for juce::ComponentPeer>, dst_type=0x7fff65c951f0 <typeinfo for juce::LinuxComponentPeer>, src2dst=0)
    at ../../.././libstdc++-v3/libsupc++/dyncast.cc:68
68      ../../.././libstdc++-v3/libsupc++/dyncast.cc: No such file or directory.
(gdb) bt
#0  __cxxabiv1::__dynamic_cast (src_ptr=0x610001179740, src_type=0x7fff65c963d8 <typeinfo for juce::ComponentPeer>, dst_type=0x7fff65c951f0 <typeinfo for juce::LinuxComponentPeer>, 
    src2dst=0) at ../../.././libstdc++-v3/libsupc++/dyncast.cc:68
#1  0x00007fff648769d4 in juce::XWindowSystem::windowMessageReceive (event=...) at ../libs/juce-current/source/modules/juce_gui_basics/native/x11/juce_linux_XWindowSystem.cpp:3680
#2  0x00007fff64874338 in operator() (__closure=0x6160004ddfb0) at ../libs/juce-current/source/modules/juce_gui_basics/native/x11/juce_linux_XWindowSystem.cpp:3046
#3  0x00007fff64883424 in std::__invoke_impl<void, juce::XWindowSystem::initialiseXDisplay()::<lambda(int)>&, int>(std::__invoke_other, struct {...} &) (__f=...)
    at /home/kjetil/site_gcc1010/include/c++/10.1.0/bits/invoke.h:60
#4  0x00007fff6487f8e9 in std::__invoke_r<void, juce::XWindowSystem::initialiseXDisplay()::<lambda(int)>&, int>(struct {...} &) (__fn=...)
    at /home/kjetil/site_gcc1010/include/c++/10.1.0/bits/invoke.h:153
#5  0x00007fff6487c8fb in std::_Function_handler<void(int), juce::XWindowSystem::initialiseXDisplay()::<lambda(int)> >::_M_invoke(const std::_Any_data &, int &&) (__functor=..., 
    __args#0=@0x7fff643e8b14: 16) at /home/kjetil/site_gcc1010/include/c++/10.1.0/bits/std_function.h:291
#6  0x00007fff646d075e in std::function<void (int)>::operator()(int) const (this=0x6160004ddfb0, __args#0=16) at /home/kjetil/site_gcc1010/include/c++/10.1.0/bits/std_function.h:622
#7  0x00007fff646cc933 in juce::InternalRunLoop::dispatchPendingEvents (this=0x60c000214240) at ../libs/juce-current/source/modules/juce_events/native/juce_linux_Messaging.cpp:186
#8  0x00007fff646c78e5 in juce::MessageManager::dispatchNextMessageOnSystemQueue (returnIfNoPendingMessages=true)
    at ../libs/juce-current/source/modules/juce_events/native/juce_linux_Messaging.cpp:300
#9  0x00007fff646c25c8 in juce::MessageManager::runDispatchLoopUntil (this=0x604002546750, millisecondsToRunFor=250)
    at ../libs/juce-current/source/modules/juce_events/messages/juce_MessageManager.cpp:92
#10 0x00007fff64535427 in SharedMessageThread::run (this=0x61300006e280) at ../libs/juce-current/source/modules/juce_audio_plugin_client/VST/juce_VST_Wrapper.cpp:212
#11 0x00007fff64631338 in juce::Thread::threadEntryPoint (this=0x61300006e280) at ../libs/juce-current/source/modules/juce_core/threads/juce_Thread.cpp:96
#12 0x00007fff646313f7 in juce::juce_threadEntryPoint (userData=0x61300006e280) at ../libs/juce-current/source/modules/juce_core/threads/juce_Thread.cpp:118
#13 0x00007fff646521df in juce::threadEntryProc (userData=0x61300006e280) at ../libs/juce-current/source/modules/juce_core/native/juce_posix_SharedCode.h:877
#14 0x00007ffff42d4ee5 in start_thread () from /lib64/libpthread.so.0
#15 0x00007fffeca06d1d in clone () from /lib64/libc.so.6

[kmatheussen]

Also, the scanner in Ardour doesn't recognize the vitalium VST2 plugin (don't know why), so I can't test there.

[kmatheussen]

Problem is that the LinuxComponentPeer instance has been deleted. As a work around at least it probably works to check that peer is in Destop::getInstance().peer (which is of type Array<ComponentPeer*>) before using it.