crash, MSVCPI20D.DLL, vector subscription out of range

[mixxxbot]

Reported by: dg3nec
Date: 2014-10-20T17:57:33Z
Status: Fix Released
Importance: Critical
Launchpad Issue: lp1383404
Attachments: 20141020.zip, debug_window_20141205.txt

---

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)

[mixxxbot]

Commented by: dg3nec
Date: 2014-10-20T17:57:33Z
Attachments: 20141020.zip

[mixxxbot]

Commented by: dg3nec
Date: 2014-10-22T16:28:45Z

---

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

[mixxxbot]

Commented by: dg3nec
Date: 2014-11-12T17:47:32Z

---

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.

[mixxxbot]

Commented by: neogeo-dc
Date: 2014-11-12T23:20:39Z

---

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

[mixxxbot]

Commented by: neogeo-dc
Date: 2014-11-15T19:53:50Z

---

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

[mixxxbot]

Commented by: rryan
Date: 2014-12-03T23:23:42Z

---

Thanks for the details shalty!

Potential fix here:
#420

Could you try it out?

[mixxxbot]

Commented by: rryan
Date: 2014-12-03T23:33:29Z

---

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.

[mixxxbot]

Commented by: rryan
Date: 2014-12-04T00:01:23Z

---

I committed a fix directly to master for the stride calculation:
a969bef

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

[mixxxbot]

Commented by: dg3nec
Date: 2014-12-04T19:19:08Z

---

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.

[mixxxbot]

Commented by: rryan
Date: 2014-12-04T19:29:53Z

---

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/

[mixxxbot]

Commented by: dg3nec
Date: 2014-12-05T16:29:58Z

---

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

[mixxxbot]

Commented by: dg3nec
Date: 2014-12-05T16:35:05Z

---

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?

[mixxxbot]

Commented by: dg3nec
Date: 2014-12-05T19:38:44Z
Attachments: debug_window_20141205.txt

---

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.

[mixxxbot]

Commented by: neogeo-dc
Date: 2014-12-08T12:23:35Z

---

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...

[mixxxbot]

Commented by: neogeo-dc
Date: 2014-12-08T12:25:31Z

---

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...

[mixxxbot]

Commented by: neogeo-dc
Date: 2014-12-08T14:05:33Z

---

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!

[mixxxbot]

Commented by: rryan
Date: 2014-12-09T18:59:20Z

---

Thank you to you two for testing!

[mixxxbot]

Commented by: rryan
Date: 2014-12-09T19:00:52Z

---

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

[mixxxbot]

Commented by: rryan
Date: 2014-12-09T19:02:15Z

---

@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!

[mixxxbot]

Commented by: dg3nec
Date: 2014-12-14T15:15:58Z

---

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

[mixxxbot]

Commented by: dg3nec
Date: 2014-12-14T15:26:16Z

---

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)

[mixxxbot]

Issue closed with status Fix Released.