CachingReaderWorker hung (Win)

Bug #1445298 reported by kramer on 2015-04-17
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Critical
Unassigned

Bug Description

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()

kramer (default-kramer) wrote :

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.

kramer (default-kramer) wrote :

Oops forgot the link in the previous post: http://download.wavetlan.com/SVV/Media/HTTP/http-aac.htm

kramer (default-kramer) on 2015-04-17
description: updated
Daniel Schürmann (daschuer) wrote :

Thank you for your reports!.

Is this a different appearance of Bug #1445320

Changed in mixxx:
importance: Undecided → Critical
milestone: none → 1.12.0
kramer (default-kramer) wrote :

They are certainly related, but may not be an exact duplicate. The difference is that in this bug, none of the other threads in Mixxx were touching the AAC file - they all looked "normal" (e.g. in a QT or OS wait). In Bug #1445320, it was clear that two Mixxx threads were deadlocked on the same AAC file.

kramer (default-kramer) wrote :

Hi Daniel, I've updated the Bug Description and I'm pretty sure now that Bug #1445320 is another appearance of the same root cause.

I tried changing to COINIT_MULTITHREADED per your comments on that bug but it doesn't seem to make a difference.

description: updated
Daniel Schürmann (daschuer) wrote :

Is the new SoundSourceAPI branch effected as well?

summary: - CachingReaderWorker hung
+ CachingReaderWorker hung (Win)
Owen Williams (ywwg) wrote :

what's the status of this?

Owen Williams (ywwg) wrote :

two months, no update... removing milestone marker for now

Changed in mixxx:
milestone: 2.0.0 → none
tags: added: windows
Uwe Klotz (uklotzde) wrote :

Most audio decoders have been improved or rewritten for Mixxx 2.1. including CachingReader. I assume that all those issues caused by legacy code are fixed now.

Changed in mixxx:
status: New → Fix Committed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers