Fix track cache to defer delete and save operations
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mixxx |
Fix Released
|
Medium
|
RJ Skerry-Ryan |
Bug Description
See: http://
http://
When an item is inserted into a QCache and the cache is full, it evicts an existing item. The eviction takes place immediately. In Mixxx, this can cause the TrackPointer refcount to go to zero, so the deleter is called, and this can immediately trigger a track save, and that can trigger a UI update, and then the UI update dives back in and tries to read the cache, which can trigger a second reentrant insert.
There are a couple ways to fix this, and we should do both to prevent future issues:
1. Cache evictions shouldn't immediately trigger a save and delete. TrackPointer's Deleter should call deleteLater, and the destructor for TIO should do the saving.
2. QCache should be rewritten so that cache eviction happens *after* the new item has been inserted
Changed in mixxx: | |
status: | New → Confirmed |
importance: | Undecided → Medium |
Changed in mixxx: | |
assignee: | nobody → RJ Ryan (rryan) |
status: | Confirmed → In Progress |
Changed in mixxx: | |
status: | In Progress → Fix Committed |
Changed in mixxx: | |
status: | Fix Committed → Fix Released |
Changed in mixxx: | |
milestone: | none → 2.0.0 |
I think an underlying problem is that TrackInfoObject refcounts dropping to 0 can cause a lot of things (database and GUI-wise) to happen that you might not expect. One way to fix this is to change TIO destruction order so that refcount dropping to zero queues the TIO for deletion and then the deletion is done via the Qt event loop.