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.
daschuer
force-pushed
the
effects_refactoring_3
branch
from
6fbe3da to
c4b081a
Compare
daschuer
force-pushed
the
effects_refactoring_3
branch
from
5b31cf8 to
7f0ba01
Compare
daschuer
force-pushed
the
effects_refactoring_3
branch
from
7a8085b to
b4dc449
Compare
daschuer
force-pushed
the
effects_refactoring_3
branch
from
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. |
ywwg
left a comment
ywwg
left a comment
There was a problem hiding this comment.
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) { |
| } | ||
| for (const ChannelHandleAndGroup& outputChannel : | ||
| std::as_const(m_registeredOutputChannels)) { | ||
| outputChannelStates[outputChannel.handle().handle()].reset( |
There was a problem hiding this comment.
what is handle().handle()? Can we make that more meaningful?
|
|
||
| void EngineEffect::deleteStatesForInputChannel(ChannelHandle inputChannel) { | ||
| m_pProcessor->deleteStatesForInputChannel(inputChannel); | ||
| //TODO: get actual configuration of engine |
There was a problem hiding this comment.
I think this TODO needs to be addressed?
|
Done. |
|
ok to merge |
5 participants
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