This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Possible race condition notes


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.

Harold


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]