Windows x86, current master branch. I think I have found the root cause of this bug. It seems to happen when the cover art scan touches an M4A/AAC file that is being played. It does not happen for mp3 files.
I can reproduce it 100% of the time now. I delete my mixxxdb.sqlite and start Mixxx. This causes a full library scan. I click cancel (the scan continues in the background) and load an M4A/AAC file and start playing it. Then I click Library -> Rescan Library in order to bring the dialog box back up. When it completes the directory scanning ("Scanning: C:\whatever\...") and transitions to "Scanning cover art", any deck that is playing an M4A/AAC goes silent, and that deck is no longer able to play any tracks (until Mixxx is restarted).
Depending on what actions I take after the problem occurs, I can observe this thread hung in different places of the code. This is the most common one, if I just exit immediately after the problem occurs:
see https://github.com/mixxxdj/mixxx/blob/master/src/util/pa_ringbuffer.c#L234
ntdll.dll!77c9015d()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!77c9015d()
KernelBase.dll!75a815e9()
KernelBase.dll!75a8151f()
kernel32.dll!758119f8()
> mixxx.exe!PaUtil_ReadRingBuffer(PaUtilRingBuffer * rbuf, void * data, long elementCount) Line 234 + 0x13 bytes C
mixxx.exe!CachingReaderWorker::run() Line 115 C++
QtCored4.dll!QThreadPrivate::start(void * arg) Line 357 C++
msvcr120d.dll!60403651()
msvcr120d.dll!60403861()
kernel32.dll!7581338a()
ntdll.dll!77ca9f72()
ntdll.dll!77ca9f45()
And here are the locals:
+ rbuf 0x00000004 {bufferSize=??? writeIndex=??? readIndex=??? ...} PaUtilRingBuffer *
data 0x00000000 void *
elementCount 16384 long
size1 65406164 long
size2 101383800 long
data2 0x03e604b0 void *
data1 0x03e604c4 void *
If the VS debugger is to be trusted, I am surprised this doesn't segfault. It appears to be trying to memcpy with a destination of 0x0. And rbuf of 0x4 can't be right either...
I haven't been able to reproduce Bug #1445320 exactly, but I'm pretty sure the root cause is the same.
I have also observed this call stack, also hung on exit. I'm not entirely sure, but it seems to happen if you eject and reload the problem track.
Here is the line it was hung on (soundsourcemediafoundation.cpp, currently line 167):
hr = m_pReader->SetCurrentPosition(GUID_NULL, prop);
And here is the trace
ntdll.dll!77c9015d()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!77c9015d()
KernelBase.dll!75a815e9()
KernelBase.dll!75a8151f()
kernel32.dll!758119f8()
mfreadwrite.dll!6bf59f93()
mfreadwrite.dll!6bf5920e()
> soundsourcemediafoundation.dll!SoundSourceMediaFoundation::seek(long filepos) Line 167 + 0x1d bytes C++
mixxx.exe!CachingReaderWorker::processChunkReadRequest(ChunkReadRequest * request, ReaderStatusUpdate * update) Line 71 C++
mixxx.exe!CachingReaderWorker::run() Line 115 C++
QtCored4.dll!QThreadPrivate::start(void * arg) Line 357 C++
msvcr120d.dll!69053651()
msvcr120d.dll!69053861()
kernel32.dll!7581338a()
ntdll.dll!77ca9f72()
ntdll.dll!77ca9f45()
This happened again. The track that failed to load and hung Mixxx can be found here - "Test 4" under "MediaCoder Files". After the problem occurs, the deck (this time deck 1) becomes unusable. It can load the waveform of an already-analyzed track but it cannot play it.
Perhaps notable is that on subsequent attempts to reproduce with the same file, Mixxx gracefully refuses to load the file. So I think at the very least it should have refused to load the file the first time.