Mixxx 1.10 crashes on certain tracks

[DJ Kaboodle]

I was using Mixxx 1.10 on Debian Linux (unstable) for a few hours with no problems. I loaded a track into a deck, and it played fine - but when it got to the end of the track, Mixxx crashed (i.e. it just shut down, with no flickering or warning or other noticeable errors).

The track is an mp3, plays fine in all players otherwise, and hs no errors that I can find. I managed to find another mp3 of the same track, ripped at a different bitrate. Same problem. Was Mixxx assuming it was the same track?

Following advice elsewhere, I turned the waveform off, and used different skins. The behaviour is exactly the same in all skins and with or without waveform off. I do not have any samples loaded, do not use vinyl control, and do not have any other programs running in the background. Mixxx is not using much CPU (about 10%), and it doesn't seem to 'peak' the CPU or memory or do anything else strange.

I will add my lspci, lshw and Mixxx logs in the following posts.

Obviously, Mixxx suddenly and apparently randomly turning itself off in the middle of a set is not good news. I was using 1.9.2 on the same track with no problems at all. I tried re-loading 1.9.2 but it seems loading 1.10 has changed configuration in my .mixxx folder so I can't go back.

I'm using Debian unstable primarily to get the latest Mixxx. I did not upgrade anything else when I upgraded Mixxx, but when I ran a full upgrade, the behaviour remained. I have used the '3' kernel and the previous, last '2' version (I can find the right kernel numbers if needed).

Is this in any way related to the other Mixxx crash reports on Launchpad?

Thanks and hope we can sort this out.

[DJ Kaboodle (djkaboodle)]

Here is my Mixxx log with the wavform ON:

[DJ Kaboodle (djkaboodle)]

and here is my Mixxx log with the waveform OFF

[DJ Kaboodle (djkaboodle)]

Here is the output of lshw (a list of all my hardware, including graphics card, memory, cpu, etc.)

[DJ Kaboodle (djkaboodle)]

And here is the output of lspci, if it helps.

[DJ Kaboodle (djkaboodle)]

Oh, and I forgot to mention that in relation to the above Mixxx logs, all I did was load one file which worked into one deck, and played around with it, letting it end. The 'faulty' file I loaded into the other deck, and again, skipped back and forth through the track, then let it play to the end, which is the last thing that I did before Mixxx died.

[Sean M. Pappalardo (pegasus-renegadetech)]

Wow, man! Extra points for the thorough testing and log gathering!

It seems the issue is given in the last line of the Mixxx logs: Fatal: []: ASSERT: "current_sample >= chunk_start_sample" in file src/cachingreader.cpp, line 414

We've seen this before and hopefully RJ will chime in here with a response since that code is his one of his areas of expertise.

[Sean M. Pappalardo (pegasus-renegadetech)]

Oh, can you possibly attach an MP3 file that causes the issue for reference?

[Owen Williams (ywwg)]

I think we'll want to get a copy of the track itself, if possible. The error that is causing the crash has to do with how the track is being decoded, so most likely there is some tiny problem with the file that most players are able to recover from but Mixxx is not handling gracefully. I'm not sure of the best way to get the track to us.

(to RJ: in general, should we really use ASSERTs? Or would it be better to catch these errors and try to recover from them? Just bombing out is not a very nice way to deal with these situations. For instance, we could just memcopy a bunch of zeros for this particular case.)

[DJ Kaboodle (djkaboodle)]

Wow! I wasn't expecting such a quick response! Thanks, guys.

And thanks, Sean, for the extra points! I need all I can get.

Here is a link to Mediafire, where you can download the offending track:

http://www.mediafire.com/?t8svolp5q5ie3dk

I included both versions of the track; the first version I tried, and the second. I renamed them, but apart from adding " - first version" and " - second version" to the filenames, they are exactly as they were when they crashed Mixxx. I'm pretty sure that the error came from the first version, which I have 'removed' in Mixxx, but I think it's still somehow connected or influencing the behaviour when I load the second version...

Hope you can do something magical with the file and find out what's causing this. And, if possible, can you let me know WHAT you do, so that I can error-check my otehr files if necessary?

Oh, by the way, in case it helps, I had a library scanning problem in Mixxx way back in maybe version 1.7 or thereabouts, and I made sure from then on that I have NOTHING except mp3 files and folders on my DJ hard drive (no playlists, no image files, etc.). I also have all weird characters and encodings removed, as it seemed all of these things can slow down performance and cause problems with a large library.

I have come across some corrupt mp3 files (ones which perhaps hadn't copied across correctly, and were only a few seconds long), but Mixxx has had no trouble at all playing these. Weird.

[RJ Skerry-Ryan (rryan)]

Thanks for uploading those tracks DJ Kaboodle. I cant reproduce the crash on my Macbook. I'll give it a try on Linux.

[RJ Skerry-Ryan (rryan)]

Hi -- can you try out the latest 1.11.0 beta to see if we've fixed this?
http://builds.mixxx.org/builds/release-1.11.x/r3487/

[Uwe Klotz (uklotzde-deactivatedaccount)]

Marked as 'Invalid', because CachingReader has been fixed in 2.1 with the introduction of the new SoundSource API. Should be fixed now.

[Swiftb0y (swiftb0y)]

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