The source code it is built from is less important than the way it is built and packaged.
Try a free/demo version from Download Ardour | Ardour Community and see if that has the same issues.
The source code it is built from is less important than the way it is built and packaged.
Try a free/demo version from Download Ardour | Ardour Community and see if that has the same issues.
Okey doke. Will try that and report back.
In my case I am using the Ardour bundle, current version.
Result: the demo version is hanging when asked to quit as well, whether I use Crtl-Q, select ‘Quit’ from the session menu, or click the close icon in the WM decoration’s titlebar.
If I do the latter, Openbox eventually asks if I want to stop the process; otherwise I have to do that myself with top or whatever is handiest.
Last message Ardour sends is “butler drops pool trash”.
Let me know if any other info would help.
This happens on openSUSE too since few days. Killing Ardour left audio system in bad shape, Reboot needed
It happend with ardour-6.9 compiled for openSUSE but also with Ardour-7.0-pre0.2475 from Nightlies…
That is interesting, could you get a backtrace when the application hangs?
run Ardour --gdb
, then inside gdb: run
to start Ardour, when the application hangs at exit, switch back to the terminal, press <Ctrl>+C
to return to the gdb prompt and run bt
(to get a backtrace. – ideally also thread apply all bt
after that.
That will produce multiple pages of output. See also https://ardour.org/debugging_ardour.
I’ll try ASAP. For now, I think that could be related to jack. Quick test with 7.0 and Alsa, seems working…
Jack-1.9.21
https://tracker.ardour.org/view.php?id=8916
indicates that the issue is in JACK (libjack specifically). Ardour calls jack_client_close()
and that function never returns.
I just did a quick test and with jackd 1.9.17 (from debian 11) it works just fine. No hang at exit.
Perhaps this is an issue with JACK 1.9.21? Do you start jackd before starting Ardour, or do you use Ardour’s Audio/MIDI dialog up start jackd?
PS.
Since this happens on both recent openSuSE and Arch, it could also be caused by a glibc update which JACK2 uses. Which libc version you have installed?
Info and gdb output added to #8916
I tried downgrading jack2 and lib32-jack2 on Arch and still get the same issue. Once I downgraded glibc it corrected the issue.
Thanks, that is very helpful.
Great to hear. Could you tell us the glibc versions? Which works for you, and which was broken?
We suspect that the problem is that glibc removes some thread cancellation points. Ardour is one of the few JACK clients that uses jack’s threaded API, and it seems that libjack now no longer can cancel the threads.
Does that imply that the correct location for a fix will be in jackd?
After further investigation, JACK was found to be innocent. The problem is a bug in glibc (unreleased 3.35.x git). libjack is affected by that, Ardour itself is not:
https://sourceware.org/bugzilla/show_bug.cgi?id=29214
Hi
Is the solution now to downgrade glibc or as it’s been identified to wait for this bug to be fixed?
thx
The bug has been fixed upstream in glibc. When your distro will pick up and distribute a new glibc containing the fix is hard to say. You could downgrade glibc (2.35 is fine), or wait, depending on your own personal situation.
If it’s helpful, I’m on Arch and the latest glibc package is glibc-2.35-5 (Not working properly). It’s fine with the glibc-2.35-4 package. The same with lib32-glibc.
Thanks for investigating this - I’m experiencing the same problem.
However I’m not sure if I understand correctly: I have to downgrade both glibc-2.35-4 and lib32-glibc?
(and why is a 32-bit library installed on my 64-bit system?)
Edit: I downgraded glibc only and now things are back to (mostly ) normal.
64 bit systems often have compatibility libraries installed to allow running 32 bit applications. That is usually not needed for applications in the distribution repository, those should all be compiled to match your base architecture, but proprietary applications may not be available in both 32 bit and 64 bit.
One common case for some people is using WINE to run Windows binaries, those are commonly built as 32 bit so you need 32 bit libraries for WINE to run 32 bit Windows applications.
just reporting that on arch, after upgrade to fresh glibc 2.35-6 the situation (ardour hanging at shutdown) sadly remains the same