Issue with Guitarix plugins confirmed to be a bug in Ardour

Installation & Configuration Linux
#1

Several months ago, i reported this bug with Guitarix plugins that sometimes causes Ardour (and no other hosts) to crash when closing the UI of a Guitarix plugin. Since i had mentioned having done some work on GxAmplifier, you jumped to the conclusion that my code was buggy, even after i mentioned it also happened with other guitarix plugins.

It would seem the problem is caused by having multiple instances of the same plugin, after changing some controls in one instance and on closing the UI of another one, boom. Plugins with more controls are more likely to be affected, which is why GxAmp (which i use heavily) was the first one to exhibit this bug.

Other users have been reporting this issue and similar ones mainly with Guitarix and Ardour. Verifying the LV2 specs with Hermann/Brummer, we confirmed that a callback is being fired from Ardour when it’s not supposed to, AFTER the UI is being torn down. My only guess as to why other plugins aren’t affected, is that the somewhat slow UI of Guitarix plugins exposes a race condition that normally goes unnoticed.

from Loading Guitarix plugins crashes Ardour · Issue #263 · brummer10/guitarix · GitHub –

This looks to me like the UI loop get called from the host after the plugin have receive the cleanup call. The plugin destroy all it's windows on that call.

    suil_x11_wrapper_idle (data=0x5555b148eb70) at ../libs/tk/suil/x11_in_gtk2.c:457
    https://github.com/Ardour/ardour/blob/master/libs/tk/suil/x11_in_gtk2.c#L457

 static gboolean
 suil_x11_wrapper_idle(void* data)
 {
 	SuilX11Wrapper* const wrap = SUIL_X11_WRAPPER(data);
 
 	wrap->idle_iface->idle(wrap->instance->handle);
 
 	return TRUE;  // Continue calling
 }

But LV2 specs says:

    /**
    Destroy the UI. The host must not try to access the widget after
    calling this function.
    */
    void (*cleanup)(LV2UI_Handle ui);

(about a possible way to fix)

You could try that. [...]
But, the point is, if that helps, it only indicate a bug in ardour. Because the specs say clearly,

    /**
    Destroy the UI. The host must not try to access the widget after
    calling this function.
    */
    void (*cleanup)(LV2UI_Handle ui);

and ui_idle() is running by the host, not by the plugin.

Hoping this gets some attention, because this bug is REALLY annoying. Only workaround now is to always remember to use the “generic” UI controls for guitarix plugins where i use more than one instance.

#2

You should post the issue on the Bug Tracker
http://tracker.ardour.org/

#3

Yep, will do, thanks.

#4

You should post the issue on the Bug Tracker

Done.

#5

Since this only affects guitarix plugins and no other LV2s it should be fixed there.

Host specific workaround for specific plugins are generally frowned upon.

#6

Working around quirky behavior or bugs of specific plugins is one thing, but the argument here seems to be that for some reason these particular plugins exposed that Ardour is violating the LV2 specification.

#7

except it isn’t. The instance is still present at this point.
It rather looks like guitarix is not following the specs.

To elaborate, Ardour does not interact with the widget after cleanup (as per spec), the extension data API is however still a valid entry point.

#8

Since guitarix works in all other hosts then it’s a bug in ardour.

See, i like jumpinig to conclusions too.

1 Like
#9

I’m not jumping to conclusions, I was involved with creating the LV2 standard, the Ardour’s LV2 implementation was done my Mr. LV2 himself…

I don’;t know the guitarix codebase, but I guess the fix would be trivial, just ignore idle callbacks or any other calls exposed by the extension interface when they are no longer appropriate.

1 Like
#10

Fair enough, that is different than described,

#11

All that being said, if there was a simple fix for this, I’d not be opposed to add it. But it is a bit of a chicken/egg issue. The widget (GTK_PLUG) being destroyed is what eventually leads to the idle call disconnect and cleanup call:

I also don’t see how the number of controls can have any effect here, and why multiple instances of the same plugin would be relevant.