Fix JACK support #1926
Merged
Fix JACK support #1926
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
to reproduce crash on teardown when using JACK as audio driver. Test is not done yet. It works properly on non-zero exit codes but not on crashes (which is what we encounter here)
jackTearDown integration test can now handle crashes of Hydrogen and shows - thanks to our crash reporter - the stack trace
theGreatWhiteShark
force-pushed
the
phil-integration-tests
branch
from
b66f61c
to
ad4e536
Compare
|
Another problem: Occassionally upstream JACK code used in our This does not occur as often as the crashes on my machine. But is still annoying. |
to prevent false positives occurring in case the OSC QUIT message gets send before Hydrogen has properly started up
probably due to some upstream JACK bugs (not sure) Hydrogen does occassionally segfault when stopping the `JackAudioDriver`. Turns out JACK has a number of issues with thread joining. During teardown of the driver we must ensure it does not do any communication, like locking the `AudioEngine` or enqueuing a message in our `Logger`. Otherwise the thread calling `jack_client_close` might segfault. Now, the callback of the `AudioEngine` checks its state twice. Once without locking (in order to `return` when it is not ready yet/anymore) and another time while locked to properly check the state. It is a little dirty. But I do not see what else we can do from within the Hydrogen code base
theGreatWhiteShark
merged commit d9f4037
into
hydrogen-music:releases/1.2
1 check passed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Probably due to some upstream JACK bugs (not sure) Hydrogen does occassionally segfault when stopping the
JackAudioDriver. Turns out JACK has a number of issues with thread joining. During teardown of the driver we must ensure it does not do any communication, like locking theAudioEngineor enqueuing a message in ourLogger. Otherwise the thread callingjack_client_closemight segfault.Now, the callback of the
AudioEnginechecks its state twice. Once without locking (in order toreturnwhen it is not ready yet/anymore) and another time while locked to properly check the state. It is a little dirty. But I do not see what else we can do from within the Hydrogen code baseFixes #1929
Previous text:
Lately we have quite a number of reports of Hydrogen crashing during shutdown or song export all related to our
JackAudioDriver(#1902, #1907, #1867).I have to admit I have seen those for quite a while now on my device. But since they are occurring very rarely (like one out of 20) and neither my Hydrogen nor JACK are in a "production" setup, I didn't bothered after giving it a first, inconclusive shot. But the JACK version I use (
1.9.21) seems to tickle down the package repos and more and more users get the same issues as well.I wrote a
Go-based integration test starting up Hydrogen hundreds of times and killing it via OSC right away. This way I'm now able to reproduce the issue.So far it looks like this is an upstream problem and code of JACK crashes when attempting to tear down the
JackAudioDriver. We might need a way to protect against crashing driver code. But I'm far from understand what is going on and still need to check and read into a couple of things first.