Re: Possible race condition notes

[Christopher Faylor <cgf at redhat dot com>]

On Sun, Apr 08, 2001 at 08:39:33PM -0400, Harold Hunt wrote:
>I've done a little messing around with WaitFor.c to see the effect of
>various changes to the file.
>
>All sessions below were run using xdmcp to connect to KDE 2.1.1 running on
>my Linux-Mandrake box; unless stated otherwise.
>
>When I say "XWin crashes", I mean that XWin exits immediately: there are no
>calls to FatalError, no STATUS_ACCESS_VIOLATION, no stack dump, no error
>message displayed of any sort; in sort the running XWin process ceases to
>exist.
>
>When I say "XWin freezes", I mean that XWin remains running, but it doesn
>not process input events, nor does it update its display window.
>
>Here are a couple things you should know before reading the test cases:
>1) WaitFor.c passes Select a list of file descriptors that it is waiting
>	for to become readable; Select is not passed a list of file
>	descriptors to watch for writability, nor is Select passed a list
>	of file descriptors to watch for exceptions.
>2) WaitFor.c passes Select a default timeout value of 10 milliseconds (E-3)
>	when running on Cygwin; all other platforms that XFree86
>	runs on use a computation to figure out what timeout value
>	to send Select.
>3) Passing Select a timeout of 0 seconds and 0 microseconds (yes, E-6)
>	causes Select to return immediately; this is known as polling.
>4) Passing Select a NULL pointer to a timeval structure as the
>	timeout causes Select to wait until one of the file descriptors
>	becomes signaled.
>
>Test cases
>1) Closing my favorite testing window, KDE Control Panel->
>	LookNFeel->Legacy Theme Importer, causes XWin.exe
>	to crash immediately, almost 100% of the time, when
>	using an unmodified WaitFor.c.  An unmodified WaitFor.c
>	passes a 10 millisecond timeout value to Select; this
>	timeout is static for Cygwin, ie. it is not computed.
>
>2) Removing all #ifdef __CYGWIN__'d sections from WaitFor.c
>	causes XWin to use a normal amount of CPU time, 1-2%,
>	when idling; if input events, like mouse clicks and key strokes,
>	are entered too quickly, ie. normal typing speed, then
>	some of the events will get lost.  My favorite window caused
>	XWin to crash after closing it 4 times.
>
>3) Following step 2, then initializing the timeval structure
>	to 0's before the call to Select on line 168 causes XWin.exe
>	to consume 100% of available CPU time when idling; XWin runs normally
>	for all other purposes.  My test window caused a crash
>	after 43 closes on my first test, on my second and third
>	tests I lost count after 80 and gave up on trying to get
>	XWin to crash.
>
>4) Following step 2, then passing Select a NULL for the pointer
>	to a time out timeval structure causes xdmcp sessions to consume
>	a normal amount of CPU time when idling; however, input events
>	get lost if they are entered too quickly, as in 2; closing
>	my test window caused a crash on the first close twice in a row,
>	and it caused a crash on the second close on the third test.
>	Running XWin with local xterm and vtwm clients causes XWin
>	to freeze immediately after initializing vtwm and displaying the xterm
>	window.
>
>I'm not even going to speculate as to what is going on.  I just wanted to
>get this information out so that other people could look at it and comment
>and/or use it as a base for their own bug hunting.

I'm not sure who else is going to be doing debugging but I just want to
make it clear that I'm not going to be debugging the X server.  This is
the first I've heard of any race conditions in select (which was written
very carefully to be race-free <which means absolutely nothing of
course>).

Maybe running the X server with strace might be useful.  This is not an
invitation to post huge strace logs here or send them to me in private
email.  However, if you notice something that looks odd, then send them
to cygwin-xfree, by all means.

It would be interesting to know what kind of handles are specifically
being sent to select?  Are these Windows handles for grabbing Windows
events like mouse clicks and focus changes?  If so, then I guess it is
possible that events are being lost.  That particular select code hasn't
been updated in years.

cgf