Mysterious Signedness Segfault

[Nick]

Yay mysterious segfault! I can't reproduce it, but for kicks the smaller of the two files that seem to have triggered it is attached. This file is also suspicious because Mixxx takes a long time to display the waveform for it.

Mixxx svn r2586 (i.e. "1.6.2 beta"), Mac OS X 10.5.

Debug: Load to player1: "/Users/nguenther/Music/The_Goat_Keeper_-_Serial_Fleuriste.mp3"
Debug: Load to player1: "/Users/nguenther/Music/Enry DJ feat. Narva9 - 2 A.M. (Take Two) The Enry DJ Remix -- Jamendo - MP3 VBR 192k - 2009.01.15 [www.jamendo.com]/02 - 2 A.M. (Take Two) (Long Mix).mp3"
Debug: SSMP3() :: Setting SRATE to 44100 from 0
Debug: file length 143283456 i
Debug: SSMP3() :: Setting SRATE to 44100 from 0
Debug: file length 26963712 i
Debug: SSMP3::ParseHeader - frames read: 10 bitrate 128
Debug: SSMP3::ParseHeader - samplerate 44100 channels 2
Debug: WGLWaveformViewer() << slotNewTrack()
Debug: WaveformRenderBeat sampleRate 44100 samplesPerPixel 441
Debug: WaveformRenderBeat :: samples = 143283456
Debug: WaveformRenderMark :: samples = 143283456
Debug: WGLWaveformViewer() << slotNewTrack()
Debug: WaveformRenderBeat sampleRate 44100 samplesPerPixel 441
Debug: WaveformRenderBeat :: samples = 26963712
Debug: WaveformRenderMark :: samples = 26963712
Debug: WaveformRenderBeat :: BPM = 0
Debug: WaveformRenderMark :: MarkPoint = 0
Debug: WaveformRenderBeat :: BPM = 0
Debug: WaveformRenderMark :: MarkPoint = 0
Debug: SSMP3() :: Setting SRATE to 44100 from 0
Debug: AnalyserWaveform: f 44100 samplesPerDownsample: -2147483648 downsamples 0 from 143283456
Segmentation Fault

[RJ Skerry-Ryan (rryan)]

This is probably fixed since we've changed AnalyserQueue and SoundTouch in 1.7.0.

[RJ Skerry-Ryan (rryan)]

Nick -- can you test it out in 1.7.0? I just checked and can't reproduce it on the sourceforge trunk, so I'm not sure that I could reproduce it originally.

[Nick (kousu)]

Yeah I don't know. This file doesn't want to crash mixxx, so it might have been the larger one I was playing or the way they interacted. Notice how I loaded them: clicked one and then quickly clicked the other. Try as I might on Linux I can't get any faster than slotNewTrack():
Debug: [Main]: Load to player1: "/home/kousu/Music/Mixxx_test/The_Goat_Keeper_-_Serial_Fleuriste.mp3"
Debug: [Reader 1]: file length 143283456 i
Debug: [Main]: WGLWaveformViewer() << slotNewTrack()
Debug: [Main]: Load to player1: "/home/kousu/Music/Mixxx_test/02 - 2 A.M. (Take Two) (Long Mix).mp3"

I *did* find this on OS X, which I don't have access to right now. Albert, can you take a look at this? I can put the mix up somewhere, but it won't fit here.

[Albert Santoni (gamegod)]

Yeah, I can try to reproduce on OS X. Can you upload the file to
senduit or somewhere?
What do I have to do to reproduce? Just try to load it really quickly
after loading another song?

Thanks,
Albert

On Mon, Apr 6, 2009 at 10:16 AM, Nick <email address hidden> wrote:
> Yeah I don't know. This file doesn't want to crash mixxx, so it might have been the larger one I was playing or the way they interacted. Notice how I loaded them: clicked one and then quickly clicked the other. Try as I might on Linux I can't get any faster than slotNewTrack():
> Debug: [Main]: Load to player1: "/home/kousu/Music/Mixxx_test/The_Goat_Keeper_-_Serial_Fleuriste.mp3"
> Debug: [Reader 1]: file length  143283456 i
> Debug: [Main]: WGLWaveformViewer() << slotNewTrack()
> Debug: [Main]: Load to player1: "/home/kousu/Music/Mixxx_test/02 - 2 A.M. (Take Two) (Long Mix).mp3"
>
> I *did* find this on OS X, which I don't have access to right now.
> Albert, can you take a look at this? I can put the mix up somewhere, but
> it won't fit here.
>
> --
> Mysterious Signedness Segfault
> https://bugs.launchpad.net/bugs/325884
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
>

[Nick (kousu)]

http://kousu.ca/hotlinks/music/The_Goat_Keeper_-_Serial_Fleuriste.mp3

I'll be honest, I don't remember exactly what I did. But judging from
the backtrace there I loaded the big song and quickly loaded the
Enrry's track over it before it had a chance to process it.

[Sean M. Pappalardo (pegasus-renegadetech)]

Not sure if this is the cause, but I noticed that the waveform analyzer doesn't abort if another track is loaded into the same deck while it's scanning the first. It should for better user response, if nothing else.

[Sean M. Pappalardo (pegasus-renegadetech)]

May need to revisit this after making the WaveformAnalyzer interruptable

[Sean M. Pappalardo (pegasus-renegadetech)]

Untargeting

[Sean M. Pappalardo (pegasus-renegadetech)]

I was able to reproduce it (single-core CPU, FWIW) by just rapidly double-clicking file after file in the library. After about 6 or so when it didn't crash, I waited until seeing the first "Waveform downsampling finished." then quickly double-clicked the next file which did it.

[Sean M. Pappalardo (pegasus-renegadetech)]

Here's a workaround to prevent crashes while the source of the problem is investigated.

[RJ Skerry-Ryan (rryan)]

OK! Pegasus_RPG and I tracked this sucker down.

The immediate problem is that AnalyserWaveform does not check that TrackInfoObject::getVisualResampleRate returns a valid value. In this case, it was returning 0, the default value, because the TrackInfoObject was never getting its visual resample rate set correctly. Once we fixed that by applying the above workaround (checking for a VRR of 0, or otherwise invalid and silly values in AnalyserWaveform) we determined that the reason the TIO's VRR was 0 had nothing to do with AnalyserQueue.

The problem lies in Track. Track uses two class member variables to keep track of the current track loaded in each deck. Since the loading of a track into a deck is asynchronous, the load process is split into two phases. The second phase was receives a pointer to the track that was loaded by the deck, but it incorrectly assumes that the class member variable and this pointer that it receives are one and the same (e.g. aliases).

There is a race condition such that these two pointers to TrackInfoObjects do not point to the same object. In this case, the second phase was setting the VRR on the class member TIO, but calling analyser queue on the TIO parameter it was passed.

A rough overview of the bug:

1) User loads track 1 into deck 1. Track sets the class pointer to the loaded track in deck 1 to be Track 1, and tells the engine to load it.
2) Before the engine has a chance to load it and call the callback to Track to start phase 2, the user loads a second track, Track 2 into deck1. Track sets the class pointer to the loaded track in deck 1 to be Track 2.
3) Engine signals to Track that Track1 is loaded into deck 1. Phase 2 of Track begins.
4) Phase 2 sets the VRR on the class pointer (which is pointing to Track 2), and calls the analyzer queue on the parameter to phase 2, which is pointing to Track 1.
5) AnalyserWaveform ends up processing Track 1, which has its VRR set to 0.

Hilarity and gnashing of teeth ensue.

I'm just glad it's not memory corruption -- just a good old fashioned race condition.

[RJ Skerry-Ryan (rryan)]

Just committed what should be a fix to this problem. (Pegasus committed a fix to AnalyserWaveform that prevents the actual segfault, this is a fix to Track which fixes the race condition which caused the problem in AnalyserWaveform to occur). lp:mixxx/1.7 r2454

Pegasus, please confirm.

[Sean M. Pappalardo (pegasus-renegadetech)]

Works fine for me.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/5093