[Bug 9026] division by zero in winealsa

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

Jörg Höhle <hoehle(a)users.sourceforge.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hoehle(a)users.sourceforge.ne
                   |                            |t

--- Comment #21 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2011-03-25 07:46:29 CDT ---
A closer look at the line numbers in the backtrace shows that it's not the call
to waveOutReset after PlaySound_WaitDone in proc_PlaySound that is causing the
crash, rather than the other call following SetEvent(psStopEvent).

        SetEvent(psStopEvent);
        waveOutReset(PlaySoundList->hWave);

The explanation is a race condition.  The player (P) reacts upon psStopEvent
and calls waveOutClose, while the app (A) calls waveOutReset.

ALSA's omr->ring_buffer_size can only be 0 after the ALSA ring buffer gets
deallocated, that is when the handle is closed.

Obviously A:waveOutReset is invoked early enough that the hWave handle is not
rejected as already closed.  The app's thread is then pre-empted,
P:waveOutClose gets in between and when the app's thread resumes execution of
waveOutReset, it operates on a stale handle and state.

As a work-around, you may comment out the above waveOutReset.  The drawback is
that a playing sound can keep playing for upto 0.667s before making room for
the next sound.

Now I'd really like to know whether it's winmm's job to prevent concurrent
execution of waveOut* and waveOutClose() -- or any other 2 winmm functions for
that matter -- or whether the apps must avoid such race conditions.

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