Crash loading first track in LateNight with loop points set

[mixxxbot]

Reported by: ywwg
Date: 2019-03-05T18:43:54Z
Status: Fix Released
Importance: Critical
Launchpad Issue: lp1818714

---

Initial discussion here:

#2016

"What's going on is m_pCurrentTrack is null at construction time. When a track is loaded, some of the signals are crossed so that onMarkChanged is getting called before slotLoadingTrack is called. Therefore, once any track loads correctly, m_pCurrentTrack will never be null again so the crash is avoided. But also, I suspect onMarkChanged is always getting called for the old track, not the current one. onMarkChanged seems to be called by pmark->connectSamplePositionChanged signal. I'm not sure what event is triggering the sample position changes though."

"ok so this only occurs on tracks where a loop has been defined. So here are the reproduce instrux:

Start mixxx fresh
Load a track that already has a loop defined
crash

The trigger to the crash is basetrackplayer.cpp where it calls m_pLoopInPoint->set(loopStart); -- setting the loop start position triggers the sample position changed signal early, before the track pointer in woverview.cpp has been updated yet. It may just be enough to put a nullptr check around the access of m_pCurrentTrack in woverview.cpp, but I'm trying to figure out if there are any bad side effects to this misordering."

(https://github.com/mixxxdj/mixxx/blob/master/src/mixer/basetrackplayer.cpp#L188)

"Yes, It only happens with the LateNight skin. All of the other Skins are fine."

[mixxxbot]

Commented by: ywwg
Date: 2019-03-05T18:56:19Z

---

For me, putting a "if (nullptr)" guard around the onMarkChanged handler fixes the problem for me, and the waveform marks are all in the right places so that may be the easiest way to fix it.

[mixxxbot]

Commented by: ferranpujolcamins
Date: 2019-03-05T19:51:22Z

---

Related bug. Set a loop on a track and tap the eject button -> Crash

[mixxxbot]

Commented by: ferranpujolcamins
Date: 2019-03-05T19:55:46Z

---

So when ejecting a track, all the hotcues are set to -1. Concurrently, m_pCurrentTrack will be set to nullptr. Thus, we really need to check for nullptr in onMarkChanged.
Besides this, I'm investigating if we need to fix anything else.

[mixxxbot]

Commented by: ferranpujolcamins
Date: 2019-03-05T20:01:49Z

---

Yes, so after loading a track we call updateCues in slotTrackLoaded. So we only need to check for nullptr on onmarkChanges and that's it. I'm opening a PR. Thank you very much for exposing the bug with such detail.

[mixxxbot]

Commented by: daschuer
Date: 2020-05-09T06:58:34Z

---

Fixed here:
#2053

[mixxxbot]

Issue closed with status Fix Released.