search

pierreguillot / Camomile

An audio plugin with Pure Data embedded that allows to load and to control patches
GNU General Public License v3.0
908 stars 63 forks source link

Linux LV2 & Ardour: generic controls crash Ardour #213

Open GModal opened 3 years ago

GModal commented 3 years ago

  1. Describe your environment Debian Buster, stable Carla 2.3.0-alpha1 Ardour 5.12.0 Qtractor 0.9.5 Camomile 1.0.7

  2. Describe the problem or the feature request Changing any LV2 parameters via the generic control interface crash Ardour.

Here is the error msg in Bash (Ardour started from shell):

(ardour-5.12.0:4242): Gdk-CRITICAL **: IA__gdk_window_get_origin: assertion 'GDK_IS_WINDOW (window)' failed

(ardour-5.12.0:4242): Gdk-CRITICAL **: IA__gdk_window_get_origin: assertion 'GDK_IS_WINDOW (window)' failed
Segmentation fault

The GUI window is not open.

GModal commented 3 years ago

V 1.0.8-beta4: Generic controls still crash Ardour (for LV2 -- as noted elsewhere, vst3 plugins are blacklisted). The Camomile GUI window works fine, and the plugin functions normally.

Quirks: -- if the plugin is bypassed, adjusting a generic control doesn't trigger a crash...but the instant the plugin is re-enabled, Ardour crashes. Even if the generic control window is already closed (and the bypass changed on the tiny plugin icon in the mixer column).

-- the small controls that can be shown/hidden below the plugin icon (mixer), all function normally with the Camomile GUI interface uninstantiated (closed). So those generic controls function correctly, strangely enough:

ardourMixerContrls

Those controls are enabled with rt-click (over plugin) menu -> Controls (with various sub-options).

Tested on both:

Debian Buster 4.19.0-13-rt-amd64 Ardour 5.12.0

Ubuntu 20.04.1 5.8.0-36-lowlatency Ardour 5.12.0

pierreguillot commented 3 years ago

Do you have the full backtrace or log of the crash? Did you use the pre-compiled binaries? Do you have the same issue with Carla and Qtraktor? If so can you give the backtrace of these crashes? Can you share the patch/plugin?

pierreguillot commented 3 years ago

I tested on Ubuntu 20.04.1 LTS - 64bit with Ardour 6.5.0 and there is no problem. Can you test it and confirm? Is there any reason not to update to Ardour 6.5.0?

pierreguillot commented 3 years ago

I tested with the Bulgroz and Castafiore plugins (from the examples package Camomile v1.0.8 beta4). Please try with these plugins.

GModal commented 3 years ago

OK, I will test later today, and let you know. My Ardour version is from the KXstudio repositories, and those binaries (plugins, apps, etc) usually play well together, and that's a painless path forward to newer versions...not the bleeding edge, but generally current enough. I do, however use the git version of Carla, from the same repos.

If I'm still having issues, I'll send you the debugging info, and my Camomile source. I try to keep the Camomile code as simple as possible, but I might be missing something crucial (although the Ardour crashes are the only major issue I see).

I usually do have an abstraction or two in my code -- but the problem manifests in the simple plugins as well (and your abstractions: param.*.pd are safe, I assume).

Maybe then we can work out if it's just a local system anomaly, and you can close this.

pierreguillot commented 3 years ago

Do you know if it's possible to download the Ardour binaries for the older version? Because I can only find Ardour 6.5 on their website. If I can reproduce the bug with an older version and then see if with the latest version this is fixed, it would be helpful.

I also checked the release notes since Ardour 5.12 and it seems that some fixes might be related to this issue. For example, "Fix crashes when editing automation points." on Ardour 6.3.

GModal commented 3 years ago

OK, I downloaded & compiled Ardour 6.5.161 from source, and was seeing the same behavior. But I could have saved myself the trouble -- Castafiore & Bulgroz both work just fine with generic control in Ardour.

So the crash issue must be related to my code. I'll attach a zip to this msg with Camomile code I wrote. AUCOP-pingolo.zip

I do try to keep source as simple as possible. Since it doesn't cause problems with generic controls in other hosts (or even in GUI form on Ardour), I'm not sure where I'm messing up. Please let me know!

GModal commented 3 years ago

Question: is the presence of program.get.pd required? Adding that to the project folder does seem to fix this... ... EDIT -- well, it did, for a while.

pierreguillot commented 3 years ago

No, none of the patches given in the examples (such as param.get, param.set, program.get, etc.) are required. Can you send the full backtrace of the crash? It would be really helpful to debug!

And by the way, the output signal of your patch is not normalized, the signal is sometimes multiplied by 2 - perhaps this can be the cause of the crash, don't you think?

PS: Some of the graphical objects have send or receive symbols that don't match to anything. And the number boxes don't have any low or high threshold.

pierreguillot commented 3 years ago

I tested your plugin on Ubuntu 20.04.1 LTS - 64bit with Ardour 6.5.0 and I had no crash. But perhaps I'm just not able to reproduce the crash. So here is what I've done:

I admit I don't know what to do now... You should give all the information you can. About your OS, your machine (the CPU and so on), the backtrace, what you did step by step to produce the crash, etc. even it seems not relevant to you.

PS: Are you sure to do things properly while compiling Ardour? Why not using the pre-compiled version?

GModal commented 3 years ago

I tried gdb with several variations of ./ardev, ./ardev -D ... ./ardbg and with vargrind. One variation crashed and froze my system for 10 minutes. The rest didn't have any symbols, even with the debug flag.

But I think I've finally got your backtrace, with the ./arcall script:

Set cursor set to default
 loading from /home/dgp/Documents/ardour6/testA6_1 as testA6_1 templ  is_new 0 bp 0
locate to 0 took 45694 usecs for 2 tracks = 22847 per track
locate to 291840 took 46336 usecs for 2 tracks = 23168 per track
locate to 0 took 43950 usecs for 2 tracks = 21975 per track
PluginWindow deleted for 0xb0c4d570

Above msgs are fairly normal.

==14935== 
==14935== Process terminating with default action of signal 11 (SIGSEGV)
==14935==  Access not within mapped region at address 0xE1
==14935==    at 0x15DF6EE: boost::shared_ptr<ARDOUR::AutomationControl>::shared_ptr(boost::shared_ptr<ARDOUR::AutomationControl> const&) (shared_ptr.hpp:422)
==14935==    by 0xE0: ???
==14935==    by 0x2300459: LV2PluginUI::write_from_ui(void*, unsigned int, unsigned int, unsigned int, void const*) (lv2_plugin_ui.cc:67)
==14935==    by 0xB5BBB208: JuceLv2UIWrapper::audioProcessorParameterChanged(juce::AudioProcessor*, int, float) (in /home/dgp/.lv2/AUCOP-pingolo.lv2/AUCOP-pingolo.so)
==14935==    by 0xB5BC81A4: juce::AudioProcessorParameter::sendValueChangedMessageToListeners(float) (in /home/dgp/.lv2/AUCOP-pingolo.lv2/AUCOP-pingolo.so)
==14935==    by 0xB5B57B3C: CamomileAudioProcessor::receiveMessage(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::vector<pd::Atom, std::allocator<pd::Atom> > const&) (in /home/dgp/.lv2/AUCOP-pingolo.lv2/AUCOP-pingolo.so)
==14935==    by 0xB5B7DD13: pd::Instance::processMessages() (in /home/dgp/.lv2/AUCOP-pingolo.lv2/AUCOP-pingolo.so)
==14935==    by 0xB5B4378F: CamomileAudioProcessor::processBlock(juce::AudioBuffer<float>&, juce::MidiBuffer&) (in /home/dgp/.lv2/AUCOP-pingolo.lv2/AUCOP-pingolo.so)
==14935==    by 0xB5BBB88D: JuceLv2Wrapper::lv2Run(unsigned int) (in /home/dgp/.lv2/AUCOP-pingolo.lv2/AUCOP-pingolo.so)
==14935==    by 0x612E78F: lilv_instance_run (lilv.h:1704)
==14935==    by 0x61412F6: ARDOUR::LV2Plugin::run(unsigned int, bool) (lv2_plugin.cc:3240)
==14935==    by 0x613EE06: ARDOUR::LV2Plugin::connect_and_run(ARDOUR::BufferSet&, long, long, double, ARDOUR::ChanMapping const&, ARDOUR::ChanMapping const&, unsigned int, long) (lv2_plugin.cc:2899)
==14935==    by 0x5E392C4: ARDOUR::PluginInsert::connect_and_run(ARDOUR::BufferSet&, long, long, double, unsigned int, long, bool) (plugin_insert.cc:1083)
==14935==    by 0x5E3AAC2: ARDOUR::PluginInsert::run(ARDOUR::BufferSet&, long, long, double, unsigned int, bool) (plugin_insert.cc:1291)
==14935==    by 0x5F08FA8: ARDOUR::Route::process_output_buffers(ARDOUR::BufferSet&, long, long, unsigned int, bool, bool) (route.cc:530)
==14935==    by 0x5F0A080: ARDOUR::Route::run_route(long, long, unsigned int, bool, bool) (route.cc:716)
==14935==    by 0x5F1E7DD: ARDOUR::Route::no_roll_unlocked(unsigned int, long, long, bool) (route.cc:3945)
==14935==    by 0x5F1E69D: ARDOUR::Route::no_roll(unsigned int, long, long, bool) (route.cc:3915)
==14935==    by 0x5A45EB9: ARDOUR::Graph::process_one_route(ARDOUR::Route*) (graph.cc:670)
==14935==    by 0x5A4B45D: ARDOUR::GraphNode::process() (graphnode.cc:80)
==14935==    by 0x5A46148: ARDOUR::GraphNode::run(int) (graphnode.h:62)
==14935==    by 0x5A4383B: ARDOUR::Graph::run_one() (graph.cc:442)
==14935==    by 0x5A44048: ARDOUR::Graph::main_thread() (graph.cc:523)
==14935==    by 0x5A4ABD8: boost::_mfi::mf0<void, ARDOUR::Graph>::operator()(ARDOUR::Graph*) const (mem_fn_template.hpp:49)
==14935==    by 0x5A4A36C: void boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> >::operator()<boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, ARDOUR::Graph>&, boost::_bi::list0&, int) (bind.hpp:259)
==14935==    by 0x5A49779: boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >::operator()() (bind.hpp:1294)
==14935==    by 0x5A48E00: boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >, void>::invoke(boost::detail::function::function_buffer&) (function_template.hpp:158)
==14935==    by 0x15BFF9E: boost::function0<void>::operator()() const (function_template.hpp:763)
==14935==    by 0x2289A2F6: ARDOUR::JACKAudioBackend::_start_process_thread(void*) (jack_audiobackend.cc:953)
==14935==    by 0x839B608: start_thread (pthread_create.c:477)
==14935==    by 0x8B3E292: clone (clone.S:95)
==14935==  If you believe this happened as a result of a stack
==14935==  overflow in your program's main thread (unlikely but
==14935==  possible), you can try to increase the size of the
==14935==  main thread stack using the --main-stacksize= flag.
==14935==  The main thread stack size used in this run was 8388608.
==14935== 
==14935== Events    : Ir sysCount sysTime
==14935== Collected : 0
==14935== 
==14935== I   refs:      0
Segmentation fault (core dumped)
GModal commented 3 years ago

Another note: Ardour 6.5.x does have VST3 support. Unfortunately (again -- here on this install), both Bulgroz and Castafiore VST3 plugins crash Ardour instantly when trying to open a generic control window.

They both seem to work fine as LV2 plugins. The other Camomile LV2 plugins that DO crash Ardour, do so only when dragging a control.

Other unusual behavior, maybe not significant: Ardour opens a small window, with the plugin GUI embedded within. Sometimes the Camomile plugins are centered in that window, sometimes they are left-aligned.

With the VST3 versions, controls are left-aligned, but any background image (if present) isn't drawn within the original plugin dimensions. The image fills the whole window container.

GModal commented 3 years ago

Is there a git for beta4? I know several submodules (JUCE, Pd, libpd, etc) are needed, and it's much easier to get those via git.

If the plugins work with a local build, it could be related to the older libraries used in KXstudio (most of my plugins are from KXstudio packages).

pierreguillot commented 3 years ago

This is the git ;) Check that https://github.com/pierreguillot/Camomile/tree/v1.0.8-beta4. I'll try to investigate your backtrace in the meantime, thank you!

pierreguillot commented 3 years ago

What surprises me in the backtrace is that the method CamomileAudioProcessor::receiveMessage effectively perform something even if the plugin window is closed. Based on your patch, this should not happen. In your patch, messages are sent ot Camomile only when interacting the GUI - that is obviously not possible if the plugin window is closed. Can you try a few things:

At this stage, onyl the DSP part of the patch remains. If the plugin stops to crash and it will facilitate the localization of the problem.

GModal commented 3 years ago

OK, I'll try eliminating those objs (and alternately try send and receive to the camomile obj directly).

Sorry, I can't find the git at that link...

GModal commented 3 years ago

OK, this LV2 plugin doesn't crash Ardour, in either the GUI or generic. Only param.get.pd is included, with a snippet of param.set.pd added.

mAmp_Pd

It doesn't update the slider when switching to the GUI, but it's a start.

Interesting Note: The Camomile GUI window is left-aligned in the window when opening the plugin. Clicking the disable / enable button centers the GUI in that window. Probably not related to our problem, just a quirk, maybe because most GUIs are larger than the minimum plugin window size in Ardour...

pierreguillot commented 3 years ago

Sorry, I can't find the git at that link...

On the main page o the repository, click on the green Code button and select the address HTTPS (https://github.com/pierreguillot/Camomile.git) or SSH (git@github.com:pierreguillot/Camomile.git).

GModal commented 3 years ago

OK, it's the main repo.

Sorry for my confusion, I thought beta4 was another branch, or a private repository. Thanks.

pierreguillot commented 3 years ago

No there is a tag at the specific commit on the branch dev/v1.0.8

GModal commented 3 years ago

Here's a backtrace of Castafiore VST3, on Beta4, Ardour 6.5.x

Camomile: Castafiore
JUCE v6.0.1
locate to 0 took 46760 usecs for 2 tracks = 23380 per track
locate to 0 took 44055 usecs for 2 tracks = 22028 per track
locate to 0 took 41896 usecs for 2 tracks = 20948 per track

Castafiore functions normally, with the GUI window.

Now GUI window closed. Selected "Edit with generic controls"

PluginWindow deleted for 0xc53217e0
==26038== 
==26038== Process terminating with default action of signal 11 (SIGSEGV)
==26038==  Bad permissions for mapped region at address 0x7C7481474C085
==26038==    at 0x7C7481474C085: ???
==26038==    by 0x73FEE8D: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.3)
==26038==    by 0x73FF23F: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.3)
==26038==    by 0x73FF532: g_main_loop_run (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.3)
==26038==    by 0x761A091: gtk_main (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.32)
==26038==    by 0x700732A: Gtkmm2ext::UI::run(Receiver&) (gtk_ui.cc:310)
==26038==    by 0x1C1AC99: main (main.cc:410)
==26038== 
==26038== Events    : Ir sysCount sysTime
==26038== Collected : 0
==26038== 
==26038== I   refs:      0
Segmentation fault (core dumped)
GModal commented 3 years ago

The dev/v1.0.8 git branch builds very smoothly; no issues compiling on Ubuntu. Unfortunately I'm seeing the same behavior with generic controls in both versions of Ardour (packaged 5.12 & local build 6.5.161).

I stripped the symbols from the libraries, but kept the originals just in case that helps with future debugging.

pierreguillot commented 2 years ago

Any update on this issue?