No UI, then DAW Crash

[hughrawlinson]

Hi, I'm running Arch with KDE under Wayland. When I try to add an AIDA-X instance to my Ardour session, whether LV2 or VST3, I open the plugin UI and it hangs for about 10s before crashing the entire Ardour session. It also exhibits the similar behaviour when run standalone - in that case it spawns a tiny window about twice as high as the KDE window title bar, and maybe 4px wide. I can't resize the window. It doesn't crash but it doesn't do anything else either. I tried calling the binary (installed via Pacman) with "-h" and "--help" to see if there were flags for debug logging, but that just launches the program as normal. I'd be very happy to provide any more data I can!

[Justin-Hoffman]

I'm experiencing a similar issue with Ardour (in Fedora 39 on x86-64) while loading the LV2 plugin when built from source. Loading the plugin with the plugin UI crashes Ardour. The plugin works and loads if I use the generic UI for interfacing with it (it's an option in Ardour). My behavior differs in that I can run the standalone plugin and see the UI fine.

I'm running X11, not Wayland, for this session.

More notes:

• If I build 1.0.0 I still get the crash in Ardour when loading the LV2 plugin with dedicated UI Actually maybe I didn't update submodules recursively

[Justin-Hoffman]

Here's a backtrace:
x00007ffff57bd0f3 in lilv_plugin_load_ports_if_necessary.part () at /lib64/liblilv-0.so.0
0x00007ffff57be7c4 in lilv_plugin_get_num_ports () at /lib64/liblilv-0.so.0
0x00007ffff793b1e5 in ARDOUR::LV2Plugin::connect_and_run(ARDOUR::BufferSet&, long, long, double, ARDOUR::ChanMapping const&, ARDOUR::ChanMapping const&, unsigned int, long) () at /usr/local/lib/ardour8/libardour.so.3
0x00007ffff764e237 in ARDOUR::PluginInsert::connect_and_run(ARDOUR::BufferSet&, long, long, double, unsigned int, long, bool) ()
at /usr/local/lib/ardour8/libardour.so.3
0x00007ffff76507c6 in ARDOUR::PluginInsert::run(ARDOUR::BufferSet&, long, long, double, unsigned int, bool) () at /usr/local/lib/ardour8/libardour.so.3
0x00007ffff771060e in ARDOUR::Route::process_output_buffers(ARDOUR::BufferSet&, long, long, unsigned int, bool, bool) ()
at /usr/local/lib/ardour8/libardour.so.3
0x00007ffff7714ca4 in ARDOUR::Route::run_route(long, long, unsigned int, bool, bool) () at /usr/local/lib/ardour8/libardour.so.3
0x00007ffff7714e69 in ARDOUR::Route::no_roll_unlocked(unsigned int, long, long, bool) () at /usr/local/lib/ardour8/libardour.so.3
0x00007ffff759a734 in ARDOUR::MidiTrack::no_roll_unlocked(unsigned int, long, long, bool) () at /usr/local/lib/ardour8/libardour.so.3
0x00007ffff7714f91 in ARDOUR::Route::no_roll(unsigned int, long, long, bool) () at /usr/local/lib/ardour8/libardour.so.3
0x00007ffff7479ed1 in ARDOUR::Graph::process_one_route(ARDOUR::Route*) () at /usr/local/lib/ardour8/libardour.so.3
0x00007ffff7482982 in ARDOUR::GraphNode::run(ARDOUR::GraphChain const*) () at /usr/local/lib/ardour8/libardour.so.3
0x00007ffff747b828 in ARDOUR::Graph::helper_thread() () at /usr/local/lib/ardour8/libardour.so.3
0x00007fffe01c500e in ARDOUR::AlsaAudioBackend::alsa_process_thread(void*) () at /usr/local/lib/ardour8/backends/libalsa_audiobackend.so
0x00007ffff40d1897 in start_thread () at /lib64/libc.so.6
0x00007ffff4158a5c in clone3 () at /lib64/libc.so.6

[Justin-Hoffman]

@falkTX - I wonder if this is some issue related to the lv2 ui size / resize logic that has been known troublesome in the past? I can look into what version(s) of lilv?, suil?, pugl? something else? that I'm building against and perhaps an update to that will resolve this.

[falkTX]

best would be to update the included dpf submodule to latest develop and re-test.
might be perhaps it was already fixed

[Justin-Hoffman]

Okay, indeed using the latest "develop" branch for dpf (and updating dpf submodules) does indeed fix this crash and I can see the UI with everything else from the 1.1.0 release tag.

I did have to add a definition for "DGL_USE_FILE_BROWSER" in order to get past an assertion in dpf/distrho/src/DistrhoPluginChecks.h at compile time for a few targets.

[Justin-Hoffman]

Is it worth considering a 1.1.1 release for this?

[falkTX]

I think so. @MaxPayne86 do you have any changes to push on a short term?

[Justin-Hoffman]

I opened #47 with the updated dpf submodule and associated CMake fixup.

I branched from main, not next, for better or worse...