crash, MSVCPI20D.DLL, vector subscription out of range

[Michael S.]

This crash comes up sometimes. Since (feeled) the last 3 builds of alpha 1.12. Mostly by loading a song.
I can produce it by loading a song with a very long playtime (45 min.) that was not loaded before.
I have made a zip with screenshot of error message, mixxx logs and gdb output.
W7/64, 1.12 alpha Build 4721 (64 bit windows version)

[Michael S. (arbeit-u)]

Info: with build 4722 (just installed) it seems to be better or solved. 200 Files Analysed without this error.

[Michael S. (arbeit-u)]

OK, meanwhile and some builds later: The Problem is not solved. In the mixxx forum for alpha 1.12 this is also written from another user.

[shalty (neogeo-dc)]

My info on the subject is here (for what is worth), still happens on recent builds

http://mixxx.org/forums/viewtopic.php?f=1&t=6617&start=20#p22777

[shalty (neogeo-dc)]

Well, after building a debug build (with VS2013CommunityEdition, btw ;)) and the last night revision, i can debug the problem

This is the stack trace. Apparently it's an issue with the waveform m_data member, that is not properly initialized (from what i see, a clear it's on the reset method, but it's missing on the constructor)

WARNING: Stack unwind information not available. Following frames may be wrong.
MSVCP120D!std::_Debug_message+0x26
MSVCP120D!std::_Debug_message+0x14
mixxx!std::vector<WaveformData,std::allocator<WaveformData> >::operator[](unsigned int _Pos = 0)+0x29
mixxx!Waveform::data(void)+0x14
mixxx!GLWaveformRendererFilteredSignal::draw(class QPainter * painter = 0x0023d5e0, class QPaintEvent * __formal = 0x00000000)+0x7f
mixxx!WaveformWidgetRenderer::draw(class QPainter * painter = 0x0023d5e0, class QPaintEvent * event = 0x00000000)+0xc3
mixxx!GLWaveformWidget::render(void)+0x51
mixxx!WaveformWidgetFactory::render(void)+0xfc
mixxx!WaveformWidgetFactory::qt_static_metacall(class QObject * _o = 0x0d1af160, QMetaObject::Call _c = InvokeMetaMethod (0), int _id = 2, void ** _a = 0x156b4178)+0xad
QtCored4!QMetaCallEvent::placeMetaCall(class QObject * object = 0x0d1af160)+0x2d
QtCored4!QObject::event(class QEvent * e = 0x156b6670)+0xec
QtGuid4!QApplicationPrivate::notify_helper(class QObject * receiver = 0x0d1af160, class QEvent * e = 0x156b6670)+0xfe
QtGuid4!QApplication::notify(class QObject * receiver = 0x0d1af160, class QEvent * e = 0x156b6670)+0x2fd
mixxx!MixxxApplication::notify(class QObject * target = 0x0d1af160, class QEvent * event = 0x156b6670)+0x438
QtCored4!QCoreApplication::notifyInternal(class QObject * receiver = 0x0d1af160, class QEvent * event = 0x156b6670)+0xa4
QtCored4!QCoreApplication::sendEvent(class QObject * receiver = 0x0d1af160, class QEvent * event = 0x156b6670)+0x39
QtCored4!QCoreApplicationPrivate::sendPostedEvents(class QObject * receiver = 0x00000000, int event_type = 0, class QThreadData * data = 0x00cd62f8)+0x2f5
QtCored4!qt_internal_proc(struct HWND__ * hwnd = 0x002003ee, unsigned int message = 0x401, unsigned int wp = 0, long lp = 0)+0x24d
USER32!gapfnScSendMessage+0x1cf
USER32!gapfnScSendMessage+0x2cf
USER32!gapfnScSendMessage+0x901
USER32!DispatchMessageW+0xf
QtCored4!QEventDispatcherWin32::processEvents(class QFlags<enum QEventLoop::ProcessEventsFlag> flags = class QFlags<enum QEventLoop::ProcessEventsFlag>)+0x5b1
QtGuid4!QGuiEventDispatcherWin32::processEvents(class QFlags<enum QEventLoop::ProcessEventsFlag> flags = class QFlags<enum QEventLoop::ProcessEventsFlag>)+0x1c
QtCored4!QEventLoop::processEvents(class QFlags<enum QEventLoop::ProcessEventsFlag> flags = class QFlags<enum QEventLoop::ProcessEventsFlag>)+0x6e
QtCored4!QEventLoop::exec(class QFlags<enum QEventLoop::ProcessEventsFlag> flags = class QFlags<enum QEventLoop::ProcessEventsFlag>)+0x176
QtCored4!QCoreApplication::exec(void)+0xfd
QtGuid4!QApplication::exec(void)+0x18
mixxx!main(int argc = 1, char ** argv = 0x00ccb110)+0x39f
mixxx!__tmainCRTStartup(void)+0x199

[RJ Skerry-Ryan (rryan)]

Thanks for the details shalty!

Potential fix here:
https://github.com/mixxxdj/mixxx/pull/420

Could you try it out?

[RJ Skerry-Ryan (rryan)]

Oh, hm. The OP mentions a 43-minute track. I think this is a bug in the waveform stride calculation. It cuts off with this hard-coded look-up-table that doesn't go above 4096*4096.

https://github.com/mixxxdj/mixxx/blob/master/src/waveform/waveform.cpp#L210

And then creates a buffer of size 4096*4096, despite setting the waveforms size to the proper size. So we think the buffer is larger than it is.
https://github.com/mixxxdj/mixxx/blob/master/src/waveform/waveform.cpp#L206

This has been around since Waveform 2.0 was added, but the new build server builds for Windows in DEBUG mode which includes bounds checking on std::vector accesses, so I think that's why this assert fires.

[RJ Skerry-Ryan (rryan)]

I committed a fix directly to master for the stride calculation:
https://github.com/mixxxdj/mixxx/commit/a969befe5b2495162d3b20356db5c8bc8692f2a4

If one of you could test both my PR and master that would be awesome. thanks!

[Michael S. (arbeit-u)]

Build 4952 (64) download, installed on W7/64. Analysed 300 Files, then loaded songs in decks and played a little bit.... Error comes up. Sorry. Then i have restartet! I have not restarted the computer after the installation. Tested a little bit. Then i have had seen a problem. Loading a song in preview was still slow down for long time. In debug window i found hundreds of lines like this:
"Debug [CachingReaderWorker 9]: SSMP3: file has differing samplerate in some head ers: "C:/Daten/Musik/Charts/Sampler Charts/70s 80s 90s Classics/Bett Midler - From A Distance.mp3" 32000 vs 44100".
After a long time mixxx comes down and works normal. I don't know if this belongs to this bug or the reason is my file.

I don't know if a restart is necessary after installing a new build. For testing it looks like so.

OK, i will need to test a little bit longer now for a statement.

[RJ Skerry-Ryan (rryan)]

Sorry Michael -- I should have been more specific about which build to try!

4952 does not have the fix.

Could you please try build 4960 or higher?
http://downloads.mixxx.org/builds/master/

[Michael S. (arbeit-u)]

No Problem. I use mixxx only private home. So i load everytime last build before using :-).

[Michael S. (arbeit-u)]

Ahhh, a question ryan besid. I have writte a midi device to transfer beats vu-meter and so on for light. To find in Forum. The new version for mixxx 1.12 with 4 decks runs good and stable. I have use the debug window for tests. Now a small question to the device JS code. I am using many timer and must stop timer. In some situations, i must go shure that special timers NOT runnig. So i send the stop timer in JS. Often the timer is NOT running. In this case i see in debug: "Timer not found" or so. Is there a possibility to check if a timer is running in a midi-device.js code?

[Michael S. (arbeit-u)]

OK, i have haerd musik with ADJ. Analysed und was selecting musik in a folder for next new year party. All is running with build 4964. Than after 2 hours, skin is frozen. Musik play to the end (deck and preview). Taskmanager says mixxx "no response". I have the debug window attached.
Dont know if it belongs to this bug.

[shalty (neogeo-dc)]

I'm sorry, i don't know why, but got no mails with the bug updates, so i've not seen this last comments till now :(

Anyway, FWIW, today i was debugging a little (with the "old" code 1 month ago, sorry), and i have done a little patch: simply put this on src\waveform\renderers\glwaveformrendererfilteredsignal.cpp (inside the ::draw method, at the beginning)

const int dataTextureSize = waveform->getTextureSize();
if (dataTextureSize <=1) {
return;
}

sometimes (still don't know why) m_data.size is 0, so getData fails. Mostly happens when the song is not previously analyzed, and if you are *not* doing debug through code setp by step until it fails...

Anyway, will update the revision and then try again...

[shalty (neogeo-dc)]

Btw, for me it fails with the same songs that sometimes works, and all of them are "normal" mp3, with normal lengths (4 to 7 minutes)...i mean, it's not caused by a especific song, but from other things, like race conditions or whatever...

[shalty (neogeo-dc)]

Well, rev 4965 works fine, through the sources and official built binaries :) (or at least i couldn't make it fail... previously was very easy to trigger)

So, for me, this can be mark as solved (the last problems of Michael S seems to be unrelated to this).

Thank you RJ Ryan!

[RJ Skerry-Ryan (rryan)]

Thank you to you two for testing!

[RJ Skerry-Ryan (rryan)]

Michael -- I filed Bug #1400831 to track your request. There isn't currently a way to do that.

[RJ Skerry-Ryan (rryan)]

@Michael

>"Debug [CachingReaderWorker 9]: SSMP3: file has differing samplerate in some head ers: "C:/Daten/Musik/Charts/Sampler Charts/70s 80s 90s Classics/Bett Midler - From A Distance.mp3" 32000 vs 44100".
After a long time mixxx comes down and works normal. I don't know if this belongs to this bug or the reason is my file.

Hm, that's odd. Could you send me this file? My email is my username at mixxx.org.

> I don't know if a restart is necessary after installing a new build. For testing it looks like so.

No need to restart your computer after installing a new build. Thanks!

[Michael S. (arbeit-u)]

Thanks allot. I tested up to now many hours (over 24) .... and the DLL Error was not coming up again. NICE :-)

[Michael S. (arbeit-u)]

Tested up to now over 24 hours..... no DLL error was coming up. NICE .... i have had a week with STABLE running MIXXX.

(Mail is on the way)

[Swiftb0y (swiftb0y)]

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