This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
Possible race condition notes
- To: "Cygx \(E-mail\)" <cygwin-xfree at sources dot redhat dot com>
- Subject: Possible race condition notes
- From: "Harold Hunt" <huntharo at msu dot edu>
- Date: Sun, 8 Apr 2001 20:39:33 -0400
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