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.
Since guitarix works in all other hosts then it’s a bug in ardour.
See, i like jumpinig to conclusions too.
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.
Fair enough, that is different than described,
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.
YOU ARE CORRECT!! This really looks like a X11 resource ownership / lifetime bug. When a plugin is closed, ANOTHER guitarix plugin that has done any kind of text display through Cairo has a chance of causing the crash.
Either commenting out the call to XCloseDisplay () OR disabling all calls to cairo_show_text () in guitarix plugins completely eliminates the crash, but this either introduces a memory leak, or makes the plugins unusable. A “workable” hack is to use XDrawString () directly for displaying text, which makes it glitchy but usable - but that’s a temporary workaround rather than an actual fix.
It doesn’t directly, but it affects the amount of text being drawn. Quickest way to reproduce: load several guitarix plugins with COMBO BOXES that contain many items. (gxAmplifier, gxCabinet, etc) Open them. Use the mouse wheel to make the combo boxes draw text many times (scroll through the list, etc). Close one instance OTHER than the one(s) that did lots of text drawing. BOOM.
This is one bitch of a bug to track down, but it looks like we’re about to FINALLY nail it.
Great detective work!
Yeah that sounds indeed like a nasty bug.
Why do plugins share resources to begin with? Can’t they all be self-contained, in which case this issue cannot happen?
Not entirely sure why a plugin like Guitarix would end up sharing resources. Maybe it wasn’t the standard back then.
What i’m wondering is, why each instance needs its own connection to the graphic system, and why it needs to be closed/reopened each time the UI is shown/hidden. If i load 5 instances of the same guitarix plugin, i see a separate call to XOpenDisplay () and XCloseDisplay () each time i open/close one of their UI… especially seeing that an X error (BadGlyph) crashes the entire host.
Because they are all independent and unrelated to each other. Plugins must not use shared resources by design. This has always been a fundamental part for Audio plugins on all platforms.
–
You could in theory do some kind of reference counting and/or use a mutex to clean up some static globals, but keep in mind that UI requests are asynchronous and different plugins may be updated concurrently which can lead to resource conflicts.
…so, if each plugin is a separate X client, how come an X error in one of them crashes all of Ardour?
Ardour (really libsuil) embedds the plugin’s XWindow. There is no process separation.
This issue is introduced by Ardour version > 8.4.0, in v8.4.0 guitarix plugins works as expected, v8.12.0 then introduce this Bug and the crash may happen. Ardour is the only host with this Problem.
I don’t know what exactly happen, but, to be clear, guitarix plugins didn’t share any resources with each other, nor use any global variables.
Guitarix plugins using cairo for text/rendering, which in turn use some shared resources (FreeFont, maybe Pango).
@delt explained it above:
if that was the issue a lot of other plugins would be affected by this as well…
Also in this case, would it not be the last instance that is being closed cause the issue (not the first)?
Do you have a backtrace of an actual crash, and a way to distinguish instances?
It is not the instance on close which crash, but a remaining instance. You could close GxCabinet and GxAmplifier-x crash. The backtrace didn’t give us more then you’ll see in the guitarix issue page. It crash in XPending (). But the Dsiplay pointer is valid (I implemented a check for debugging) and it is not the ui_idle loop from the plugin which close. As I said, Ardour versions <= 8.4.0 didn’t have this issue. I don’t know if Ardour using now something like XESetFreeFont() or XESetCloseDisplay() under the hood.
The main difference is that since then system-wide gtk2 is no longer used, but it’s ancient history in software development, and telling users to use Arodur 8.3 for guitarix isn’t really an option.
No, no such calls in Ardour’s source tree (incl. x11/gtk) at all.
Ok, let’s try some debugging a-la Holmes:
Say you have one Guitarix plugin, and one LSP plugin, both use Pango/Cairo to draw text. Closing them works fine, right?
So now you load a second Guitarix plugin. What changes?
–
PS. I cannot reproduce this crash here. Neither with local build nor official Ardour 9 binary. Though I do have a 2024 (?) version of guitarix here from debian: guitarix-lv2 0.46.0+dfsg-1
It’s not easy to make it crash. You must move the combobox entry and the popdown menu and then close a other instance. On the UI side there have nothing changed in the LV2 plugs since the 0.46.0+dfsg-1 version from debian. I haven’t checked in combination with a LSP plugin, but, that’s a good idea. I’ll try it. Just, for now I’m running out of time, I must put that on my schedule for next week.
Or, maybe I should update the libxputty version from Guitarix to the last revision.
Here i’m consistently able to make it crash - load 4 or 5 instances of, let’s say GxAmplifier (because it has 3 combo boxes, and the amp model box has lots of entries), close one instance after scrolling through the combo boxes of the other instances.
So that might be the cause, or is there any other changes that might cause this bug?
Yep, so far was not able to make a guitarix plugin crash from another plugin, just tested with LSP Impulse Response scrolling several times through a directory with hundreds of IR files.
That’s what i was hoping the difference between Ardour 8.4 and 8.12 would point us towards. I hope to understand what exactly causes this bug, not just patch it / work around it.k
Honestly that’s the first thing i’d try.
Also a small update: i just noticed that if the instance is closed when scrolling through text boxes in other instance(s), THEN you open it, THEN you close it right after, the crash also happens.
Gonna do more testing once i get home…
No crash here after few minutes of test. 2 audio tracks each with 6 Guitarix-amp-x, Lsp-limiter and Lsp-Spectrum Analyzer.
openSUSE TW, Ardour-9.2 (official) and lv2-guitarix-0.47
Hard to say, but since libsuil’s x11_in_gtk is indirectly affected, it may be related.
Quick git log grep also shows that 8.2. → 8.3 fixes plugin window visibility when re-opening sessions (keep track of open windows, 3355e753b). Ardour 8.4 to 8.5 has some LV2 related realtime fixes (replace heap allocation with stack b96d55645, 6d29a0e99). 8.7 has optimization for port value changes and DSP/UI communication (7dac8994f69, 7dac8994f69) , LV2 thread priorities changed in 8.8 and the internal API was updated to C++11 (instead of boost)…
but nothing that can directly explain this.
What baffles me is that each gx *.lv2 plugin is a dedicated shared object:
$ ls -l /usr/lib/lv2/gx*.lv2/*gui*so | wc -l
69
So it’s odd that they can interfere with each other to begin with…