Mail Archives: cygwin/2012/12/21/05:33:41
On Dec 21 01:30, Tom Honermann wrote:
> I spent most of the week debugging this issue. This appears to be a
> defect in Windows. I can reproduce the issue without Cygwin. I
> can't rule out other third party kernel mode software possibly
> contributing to the issue. A simple change to Cygwin works around
> the problem for me.
>
> I don't know which Windows releases are affected by this. I've only
> reproduced the problem (outside of Cygwin) with Wow64 processes
> running on 64-bit Windows 7. I haven't yet tried elsewhere.
>
> The problem appears to be a race condition involving concurrent
> calls to TerminateProcess() and ExitThread(). The example code
> below minimally mimics the threads created and exit process/thread
> calls that are performed when running Cygwin's false.exe. The
> primary thread exits the process via TerminateProcess() ala
> pinfo::exit() in winsup/cygwin/pinfo.cc. The secondary thread exits
> itself via ExitThread() ala Cygwin's signal processing thread
> function, wait_sig(), in winsup/cygwin/sigproc.cc.
>
> When the race condition results in the undesirable outcome, the exit
> code for the process is set to the exit code for the secondary
> thread's call to ExitThread(). I can only speculate at this point,
> but my guess is that the TerminateProcess() code disassociates the
> calling thread from the process before other threads are stopped
> such that ExitThread(), concurrently running in another thread, may
> determine that the calling thread is the last thread of the process
> and overwrite the process exit code.
>
> The issue also reproduces if ExitProcess() is called in place of
> TerminateProcess(). The test case below only uses
> TerminateProcess() because that is what Cygwin does.
>
> Source code to reproduce the issue follows. Again, Cygwin is not
> required to reproduce the problem. For my own testing, I compiled
> the code using Microsoft's Visual Studio 2010 x86 compiler with the
> command 'cl /Fetest-exit-code.exe test-exit-code.cpp'
>
> test-exit-code.cpp:
Wow. Thanks for this testcase. I tried to reproduce the issue and
I was not able to reprodsuce it on a single-CPU, single-core setup,
but I could reproduce it almost immediately on a dual-core system,
twice in a row in under 5 secs.
> The workaround I implemented within Cygwin was simple and sloppy. I
> added a call to Sleep(1000) immediately before the call to
> ExitThread() in wait_sig() in winsup/cygwin/sigproc.cc. Since this
> thread (probably) doesn't exit until the process is exiting anyway,
> the call to Sleep() does not adversely affect shutdown. The thread
> just gets terminated while in the call to Sleep() instead of exiting
> before the process is terminated or getting terminated while still
> in the call to ExitThread(). A better solution might be to avoid
> the thread exiting at all (so long as it can't get terminated while
> holding critical resources), or to have the process exiting thread
> wait on it. Neither of these is ideal. Orderly shutdown of
> multi-threaded processes is really hard to do correctly on Windows.
>
> Since the exit code for the signal processing thread is not used,
> having the wait_sig() thread (and any other threads that could
> potentially concurrently exit with another thread) exit with a
> special status value such as STATUS_THREAD_IS_TERMINATING
> (0xC000004BL) would enable diagnosis of this issue as any process
> exit code matching this would be a likely indicator that this issue
> was encountered.
Maybe the signal thread should really not exit by itself, but just
wait until the TerminateThread is called. Chris?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -