[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