http://bugs.winehq.org/show_bug.cgi?id=4093
marcus@jet.franken.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |marcus@jet.franken.de
------- Additional Comments From marcus@jet.franken.de 2006-20-08 16:15 ------- i spent quite some time trying to find out why this happens.
The pattern I see is:
- multiple threads doing IDsDriverBufferImpl_GetPosition()
They try to enter the critical section and have RtlpWaitForCriticalSection in their backtrace.
- 2 of them have additional in the stacktrace a DSDB_MMAPCopy()
Somehow the piece of code doing this gets injected on top of the previous stack? It is unclear how this is done, but it might be ALSA specific.
And yes, I have added some debug code that show this is the case (and not just some random stack corruption).
What I suspect is that one the calls has just acquired the lock, but the pushed on top instruction flow tries to lock it again, but fails.
Sample gdb bt excerpt:
(gdb) bt #0 0x7bc287b8 in RtlpWaitForCriticalSection (crit=0x181244) at critsection.c:64 #1 0x7bc28c99 in RtlEnterCriticalSection (crit=0x181244) at critsection.c:508 #2 0x612cdb03 in DSDB_MMAPCopy (pdbi=0x181238, mul=1) at audio.c:3120 #3 0x6136cf6e in snd_output_buffer_open () from /usr/lib/libasound.so.2 ... #22 0x7bc5551b in wine_server_call (req_ptr=0x181244) at server.c:324 #23 0x612cd775 in IDsDriverBufferImpl_GetPosition (iface=0x181238, lpdwPlay=0x34fd58, lpdwWrite=0x34fd54) at audio.c:3378 #24 0x605d5488 in DSOUND_PrimaryGetPosition (device=0x1709d8, playpos=0x34fd58, writepos=0x34fd54) at primary.c:296 #25 0x605bd0ad in IDirectSoundBufferImpl_GetCurrentPosition (iface=0x3490028, playpos=0x34fd90, writepos=0x0) at buffer.c:472
#0 0x7bc287b8 in RtlpWaitForCriticalSection (crit=0x181244) at critsection.c:64 #1 0x7bc28c99 in RtlEnterCriticalSection (crit=0x181244) at critsection.c:508 #2 0x612cdb03 in DSDB_MMAPCopy (pdbi=0x181238, mul=1) at audio.c:3120 #3 0x6136cf6e in snd_output_buffer_open () from /usr/lib/libasound.so.2 ... #59 0x7bc28725 in RtlpWaitForCriticalSection (crit=0x181244) at critsection.c:64 #60 0x7bc28c99 in RtlEnterCriticalSection (crit=0x181244) at critsection.c:508 #61 0x612cd775 in IDsDriverBufferImpl_GetPosition (iface=0x181238, lpdwPlay=0x616c2a18, lpdwWrite=0x616c2a14) at audio.c:3378 #62 0x605d3620 in DSOUND_timer (timerID=1, msg=4294967292, dwUser=1509848, dw1=4294967292, dw2=4294967292) at mixer.c:963 #63 0x6062944c in TIME_MMSysTimeThread (arg=0x6067bc20) at time.c:95 #64 0x7b88cd38 in THREAD_Start (ptr=0xfffffffc) at thread.c:76
The threads might have received SIGUSR1 calls? I looked at one of the inner RtlpWaitForCritSections and $eax is -4 (-EINTR) which might suggest interruption due to signal.