http://bugs.winehq.org/show_bug.cgi?id=28617
--- Comment #2 from Andrew Eikum aeikum@codeweavers.com 2011-10-17 13:02:56 CDT --- Created attachment 36956 --> http://bugs.winehq.org/attachment.cgi?id=36956 dsound: Don't make the capture buffer object address public until it is prepared
(In reply to comment #1)
Created attachment 36769 [details] +tid,+winmm,+mmdevapi,+dsound,+alsa log
I wonder if these warnings might be related:
... warn:alsa:AudioClient_GetCurrentPadding Xrun detected ...
They're repeated several times in the log.
Nope. There's some problem creating the audio capture buffer. FlatOut2 apparently does no error checking, which results in the crash. You can see this in your log here (line 1385):
0009:trace:dsound:IDirectSoundCaptureImpl_CreateCaptureBuffer (0x3728d70,0x32fc74,0x6b0a20,(nil)) 0009:trace:dsound:IDirectSoundCaptureBufferImpl_Create (0x3728c80,0x6b0a20,0x32fc74) 0009:trace:dsound:IDirectSoundCaptureBufferImpl_Create (formattag=0x0001,chans=1,samplerate=8000,bytespersec=16000,blockalign=2,bitspersamp=16,cbSize=0) 0009:trace:mmdevapi:MMDevice_Activate (0x135100)->(0x5dd7f728,1,(nil),0x3728cdc) 0009:trace:alsa:AUDDRV_GetAudioEndpoint "default" 0x135100 1 0x3728cdc 0029:trace:dsound:IDirectSoundCaptureBufferImpl_GetCurrentPosition (0x3728f50,(nil),0x517ea4c) 0029:warn:dsound:IDirectSoundCaptureBufferImpl_GetCurrentPosition no driver 0029:trace:dsound:IDirectSoundCaptureBufferImpl_Lock (0x3728f50,00000000,00007998,0x517ea40,0x517ea54,0x517ea50,0x517ea30,0x00000000) at 1571 0029:trace:dsound:IDirectSoundCaptureBufferImpl_Lock invalid call 0029:trace:dsound:IDirectSoundCaptureBufferImpl_Lock returning 88780032 wine: Unhandled page fault on read access to 0x00000f9f at address 0x604702 (thread 0029), starting debugger...
Then a bit further down, you see thread 0009 resume with a successful MMDevice_Activate() call. So I think this is a concurrency issue. My guess is the game's audio capture thread (0029) continually checks for its IDirectSoundCaptureBuffer pointer to be non-NULL and starts working with it as soon as it is. Since our implementation assigns the buffer object directly to the pointer at allocation time, their capture thread takes it and tries to use the incomplete object before CreateCaptureBuffer() returns.
So here's a patch which only fills in the pointer on success. Does it fix the crash? If not, can you throw another log at me?