DEBUG_ASSERT when changing tree view item

Bug #1837315 reported by Daniel Schürmann
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Fix Released
Medium
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
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:
https://github.com/mixxxdj/mixxx/issues/9697

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.