crash / GUI freeze when loading track into deck with passthrough enabled

Bug #1977662 reported by ronso0
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released

Bug Description

* configure outputs and VC input for deckN
* load track <-- !
* enable passthrough
* load another song
* deck overview shows "Analyzing..." string then GUI freezes instantly
* GUI updates every 30 seconds or so, one Mixxx thread uses 100% of CPU
* click passthrough button
* on next GUI update it 'unfreezes'

I could reproduce this with I/O both on integrated card of TerminalMix 2/4, as well as with loopback device and no controller attached.
Only happenes when a track is loaded when enabling passthrough. Enabling passthrough and then loading a track as well as ejecting works flawlessly.

reproducible with
2.3 352f75428b --> crashes with std::bad_alloc, see backtrace
sometimes also prints
Warning [Main]: CachingReader - Loading a new track while loading a track may lead to inconsistent states
^ up to 3 times
Critical [Engine]: DEBUG ASSERT: "atomicLoadRelaxed(m_state) == STATE_TRACK_LOADING" in function void CachingReader::process() at /src/engine/cachingreader/cachingreader.cpp:285
terminate called after throwing an instance of 'std::bad_alloc'
  what(): std::bad_alloc

main c126267767 --> freezes until passtrhough is disabled

vc type doesn't matter

Revision history for this message
ronso0 (ronso0) wrote :
description: updated
ronso0 (ronso0)
description: updated
ronso0 (ronso0)
description: updated
Revision history for this message
ronso0 (ronso0) wrote :

The crash seems to be caused by the waveform renderer. Choosing 'Empty' or the vsync test prevents the crash.
Crash occurs with any overview.

Side effect:
With any (main) waveform renderer, when loading a track to a passthrough deck the overview playposition would get stuck at the center.
With no renderer, the playposition is reset to the beginning.
In both cases, disabling passthrough makes the playpos seek to the desired place.

Revision history for this message
ronso0 (ronso0) wrote :

Okay, as the backtrace shows the culprit is
though I just don't get (yet) how this is related to passthrough...

Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote (last edit ):

Non-terminating iterator, unlimited growth of memory, crash when calling m_beats.resize().

Also reported here:

Revision history for this message
ronso0 (ronso0) wrote :

Yes, this is the symptom.

The root cause seems to be the engine playposition:
if passthrough is enabled, loading a track queues the new position. only after disabling passthrough the engineDeck will process the buffer and processSeek() is called.
Thus, with passthrough kInitialPlayPosition persists (std::numeric_limits<double>::lowest()) which leads to confusion down the line.

I could add a workaround, probably considered a hack, but it definitely solves the GUI freeze / crash.

Changed in mixxx:
status: New → In Progress
assignee: nobody → ronso0 (ronso0)
Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :
ronso0 (ronso0)
Changed in mixxx:
assignee: ronso0 (ronso0) → Uwe Klotz (uklotzde)
status: In Progress → Fix Committed
Changed in mixxx:
status: Fix Committed → Fix Released
Revision history for this message
Swiftb0y (swiftb0y) wrote :

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.