[Bug 15423] New: mIRC enters deadlock after a second playback attempt

wine-bugs at winehq.org wine-bugs at winehq.org
Fri Sep 26 13:21:53 CDT 2008


http://bugs.winehq.org/show_bug.cgi?id=15423

           Summary: mIRC enters deadlock after a second playback attempt
           Product: Wine
           Version: CVS/GIT
          Platform: PC
               URL: http://www.mirc.com/get.html
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: winmm&mci
        AssignedTo: wine-bugs at winehq.org
        ReportedBy: nodisgod at yahoo.com


Created an attachment (id=16285)
 --> (http://bugs.winehq.org/attachment.cgi?id=16285)
mIRC thread backtrace

With current Git (wine-1.1.5-207-gc425c8a), when using the splay mIRC command
to play back a WAV file, the first playback attempt succeeds, but a second
attempt causes mIRC to lose all responsiveness. A bit of investigation seemed
to indicate that the first playback thread blocks inside WAVE_mciPlayWaitDone()
in line 853 of dlls/mciwave/mciwave.c after exiting the playback loop:

    WAVE_mciPlayWaitDone(wmw); /* to balance first buffer */

which does not allow the code after it to run. When mIRC tries to close the 
device, it ends up waiting on

    while (wmw->dwStatus != MCI_MODE_STOP)
        Sleep(10);

in WAVE_mciStop() in the process of closing the device, thus resulting in a
deadlock. Removing the line in mciwave.c eliminates the deadlock, although the
resulting mciwave behavior when attempting to play back another stream in mIRC
while a stream is playing does not match the behavior on Windows. Backtraces
and winmm/mciwave traces are attached.


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.



More information about the wine-bugs mailing list