DEBUG_ASSERT when changing tree view item

Bug #1837315 reported by Daniel Schürmann
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Daniel Schürmann

Bug Description

This has happens during AutoDJ development derived from current master.

Debug [AnalyzerThread 0 #1]: Keys version/sub-version unchanged since previous analysis. Not analyzing.
Debug [AnalyzerThread 0 #1]: AnalyzerWaveform - Waveform generation for track 8 done 0 s
Debug [Main]: MixxxLibraryFeature::activate()
Debug [Main]: WTrackTableView::loadTrackModel() LibraryTableModel(0x3dd2620)
Debug [Main]: LibraryTableModel(0x3dd2620) select() took 2 ms 68
Critical [Main]: DEBUG ASSERT: "row < m_children.size()" in function TreeItem* TreeItem::child(int) const at src/library/treeitem.cpp:60
Fatal [Main]: ASSERT failure in QList<T>::operator[]: "index out of range", file /usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h, line 514

Revision history for this message
Daniel Schürmann (daschuer) wrote :

There is an issue during updating the bold state of a recently generated history playlist.
That was not already drawn by the GUI.

Changed in mixxx:
status: New → In Progress
importance: Undecided → High
importance: High → Critical
assignee: nobody → Daniel Schürmann (daschuer)
Changed in mixxx:
milestone: none → 2.2.2
Revision history for this message
Daniel Schürmann (daschuer) wrote :

Strange. I can't reproduce the issue with the 2.2 branch but with plain master.

We can easily solve the crash by iterating over the rootItem->childs instead of m_playlistList, but unfortunately this does not solve the root issue.

The crash happens when I see in the tree a current history playlist (5) marked with a "->", but m_playlistList already has a invisible history playlist with prefix (6).

How can this situation happen?

Revision history for this message
Daniel Schürmann (daschuer) wrote :

I got it. It is an issue with running two Mixxx instances in parallel.
In this case a the new history playlist is silently created in the database without updating the GUI.
The next call to BasePlaylistFeature::updateChildModel() the fetches whole m_playlistList from the database but updates only the recently changed playlist inside the GUI and not the changes do to the other Mixxx instance.

I think the best solution is to refresh only the effected playlist in m_playlistList.
This fixes the crash and improves the performance.
Concurrent DB changes are not discovered as Mixxx is not designed for it.

Revision history for this message
Daniel Schürmann (daschuer) wrote :
Changed in mixxx:
importance: Critical → Medium
Changed in mixxx:
status: In Progress → Fix Committed
Uwe Klotz (uklotzde)
Changed in mixxx:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers