[Bug 4093] deadlock in alsa driver: CriticalSection WINEALSA_mmap_crst

[Wine Bugs]

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


marcus at jet.franken.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marcus at jet.franken.de




------- Additional Comments From marcus at 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. 
 
 

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.