-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Effect crasher fix #4707
Effect crasher fix #4707
Conversation
…ers after a channel has been disabled.
…hen a stream is paused. Fixes lp1966607
…r perspective it is no difference between disabling an effect or a chain.
6fbe3da
to
c4b081a
Compare
5b31cf8
to
7f0ba01
Compare
7a8085b
to
b4dc449
Compare
bee0ffa
to
2250eaa
Compare
This one merges cleanly again. |
Who is able to review this? |
This is a regression since mixxxdj#4771
This PR has discovered a missing null check introduced here: |
Tested this PR vs main on multiple machines: the effects toggling does not cause a crash with this PR, while I have had multiple crashes on main branch toggling FX on or off. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great, much cleaner! I agree that we can merge to 2.4 and do some testing and fixing. I made a couple of notes.
inputChannelHandleNumber++; | ||
} | ||
m_channelStateMatrix.clear(); | ||
//if (kEffectDebugOutput) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
uncomment debug guards
for (const ChannelHandleAndGroup& outputChannel : | ||
std::as_const(m_registeredOutputChannels)) { | ||
outputChannelStates[outputChannel.handle().handle()].reset( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is handle().handle()? Can we make that more meaningful?
src/engine/effects/engineeffect.cpp
Outdated
|
||
void EngineEffect::deleteStatesForInputChannel(ChannelHandle inputChannel) { | ||
m_pProcessor->deleteStatesForInputChannel(inputChannel); | ||
//TODO: get actual configuration of engine |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this TODO needs to be addressed?
Done. |
ok to merge |
This PR fixes a crasher due to unsafe handling of the effect state lifetime and concurrent access to m_chainStatusForChannelMatrix in EngineEffectChain::deleteStatesForInputChannel()
https://bugs.launchpad.net/mixxx/+bug/1775497
This has been introduced in Mixxx 2.1 via #1468.
Under normal conditions the crash does not happen, but it happens whenever the order of execution of the main and engine thread is disturbed due to an overload condition. A locking that is able to prevent this is missing.
The delete attempt from in the main thread might be delayed and the engine is still accessing the memory. This causes a crash. The other issue is that the m_chainStatusForChannelMatrix is written concurrently from the engine and the master thread which must not happen. It must only change state at the beginning of the new engine callback. #4487
This PR also fixes https://bugs.launchpad.net/mixxx/+bug/1966607 where the effect was not ramped up/down during loading a new track.
To solve both issues, enabling and disabling of an effect is no done in the same way regardless of which control disables the effect. The effect state is initialized on demand, but it is keep until the effect is unloaded under all conditions.
Before it was kept if the effect was disabled via the effect enable button, but it was deleted when the effect was disabled via a routing button.
This allows finally to delete all the brittle code around EngineEffectChain::deleteStatesForInputChannel().
This is big PR and the crasher happens only rarely, I have decided to build this PR on top of 2.4, which allows us to test it well during beta phase. A backport to 2.3 is not simple, because of the recent effect refactoring.
I have tried to build self contained commits, that can be reviewed if the whole PR