Don't process ejected tracks #11334
Don't process ejected tracks #11334
Conversation
| bool hasStableTrack = m_pTrackLoaded->toBool() && m_iTrackLoading.loadAcquire() == 0; | ||
| if (hasStableTrack && m_pause.tryLock()) { |
There was a problem hiding this comment.
This might fix the issue, though my guess is that the problem stems from a memory access ordering issue. Have you tried refactoring m_iTrackLoading to a std::atomic<bool> and then use memory_order::seq_cst accesses everywhere?
There was a problem hiding this comment.
The issue fortunately is pretty clear.
We have identified dff90d2
as the first failing commit.
I have introduced an extra engine callback where the track is already ejected. m_pTrackLoaded is false than.
This is required to clear the effect buffers.
Calling processTrackLocked() without a track is obviously wrong.
I have not found out where exactly the bad memory access happens. Valgrind reveals only the symptom inside Soundtouch.
There was a problem hiding this comment.
Are you sure that the CO is not subject to data-races?
There was a problem hiding this comment.
Yes, because m_pTrackLoaded and m_iTrackLoading are atomic and only changed under the m_pause lock.
|
@RadioDM has confirmed that his bug is fixed 🎉 |
|
I have rebated onto upstream/2.4 to have #11333 included. |
This fixes the hard to reproduce crash reported in #11257