Possible critical section bug - lock by invalid thread
In several RPG I have been testing, I have found deadlocks on the sound thread - the sound loops on and on, and the program freezes. At the same time, I see messages like the following: fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fe32708)->(00010022,00000008) err:dsound:DSOUND_MixOne underrun on sound buffer 0x7fe82310 err:dsound:DSOUND_MixOne underrun on sound buffer 0x7fe82880 err:wave:DSDB_MMAPCopy mmap partially failed. err:ntdll:RtlpWaitForCriticalSection section 0x7fe3336c "?" wait timed out in thread 000a, blocked by 0000, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7fe3336c "?" wait timed out in thread 0009, blocked by 0000, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7fe3336c "?" wait timed out in thread 000a, blocked by 0000, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7fe3336c "?" wait timed out in thread 0009, blocked by 0000, retrying (60 sec) I thought that DirectSound was not performing locking properly, until I noticed the following: all the times I see this deadlock, the thread ID "responsible" for the deadlock is 0000. From a little digging in the code, I see that 0 is the value used in the critical section when it is not held by any thread. So these are potentially cases where a previous thread frees the critical section, but somehow the critical section remains locked. I think I saw a select() call in the wineserver, used as an implementation for this wait, and this select() call times out, resulting in the behavior shown above. All these instances happen under heavy CPU load, so I suspect some sort of race condition. If I really try and bog down the CPU, I can even trigger this deadlock on the DirectSound tests (under ALSA). Could anybody who knows about Wine critical sections comment on this? I do not really understand the implementation of critical sections at the wineserver side (other than the fact that a select() is used somewhere), so I could take a long time to unravel this bug. This problem does not seem specific to DirectSound as far as I could tell, so this might be affecting a couple other apps under Wine. Also, comments on how I could supply more information on this are welcome. Alex Villacís Lasso
I also see this in PokerStars.NET (an online poker game) In my case, I believe the threads are valid however. I'll check on that and get back to you. I notice it after playing the game for about a half-hour, sometimes a bit longer. When this happens, I also noticed that I can barely move my mouse, CPU usage is maxed, and the hard drive is busy too. I think your theory about a race condition is probably correct. The odd thing is I see this in both ALSA and OSS sound modes, so I don't think the problem is there, but is more likely to be somewhere the server, because any critical section used by a running Windows program seems to be affected. I get wait timeouts like what you're showing everywhere in Wine (x11drv, sound, anything) Perhaps you should post a full output the errors you get someplace on the web. (I imagine it'll be too big for the list) James On Mon, 2005-08-29 at 14:07 -0500, Alex Villacís Lasso wrote:
In several RPG I have been testing, I have found deadlocks on the sound thread - the sound loops on and on, and the program freezes. At the same time, I see messages like the following:
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fe32708)->(00010022,00000008) err:dsound:DSOUND_MixOne underrun on sound buffer 0x7fe82310 err:dsound:DSOUND_MixOne underrun on sound buffer 0x7fe82880 err:wave:DSDB_MMAPCopy mmap partially failed. err:ntdll:RtlpWaitForCriticalSection section 0x7fe3336c "?" wait timed out in thread 000a, blocked by 0000, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7fe3336c "?" wait timed out in thread 0009, blocked by 0000, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7fe3336c "?" wait timed out in thread 000a, blocked by 0000, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7fe3336c "?" wait timed out in thread 0009, blocked by 0000, retrying (60 sec)
I thought that DirectSound was not performing locking properly, until I noticed the following: all the times I see this deadlock, the thread ID "responsible" for the deadlock is 0000. From a little digging in the code, I see that 0 is the value used in the critical section when it is not held by any thread. So these are potentially cases where a previous thread frees the critical section, but somehow the critical section remains locked. I think I saw a select() call in the wineserver, used as an implementation for this wait, and this select() call times out, resulting in the behavior shown above.
All these instances happen under heavy CPU load, so I suspect some sort of race condition. If I really try and bog down the CPU, I can even trigger this deadlock on the DirectSound tests (under ALSA).
Could anybody who knows about Wine critical sections comment on this? I do not really understand the implementation of critical sections at the wineserver side (other than the fact that a select() is used somewhere), so I could take a long time to unravel this bug. This problem does not seem specific to DirectSound as far as I could tell, so this might be affecting a couple other apps under Wine. Also, comments on how I could supply more information on this are welcome.
Alex Villacís Lasso
Alex Villacís Lasso <a_villacis(a)palosanto.com> writes:
Could anybody who knows about Wine critical sections comment on this? I do not really understand the implementation of critical sections at the wineserver side (other than the fact that a select() is used somewhere), so I could take a long time to unravel this bug. This problem does not seem specific to DirectSound as far as I could tell, so this might be affecting a couple other apps under Wine. Also, comments on how I could supply more information on this are welcome.
The most likely cause is that a thread got killed while trying to release the section. If you see calls to TerminateThread that would be a prime suspect. -- Alexandre Julliard julliard(a)winehq.org
participants (3)
-
Alex Villacís Lasso -
Alexandre Julliard -
James Liggett