Intermittent failures retrieving process exit codes

Tom Honermann thonermann@coverity.com
Fri Dec 21 19:45:00 GMT 2012


On 12/21/2012 07:15 AM, Nick Lowe wrote:
> Briefly casting my eye at the test case, as a general point, remember
> that these termination APIs all complete asynchronously and I do not
> believe it has ever been safe or correct to call another while one is
> still pending - you are in undefined, edge case behaviour territory
> here.

These comments do not match my understanding of these APIs.  MSDN 
documentation contradicts some of this as well.

> Win32's TerminateThread/ExitThread, that in turn calls the native
> NtTerminateThread, only requests cancellation of a thread and returns
> immediately.
> One has to wait on a handle to the thread know that termination has
> completed, for which the synchronise standard access right is
> required.
> The same is true of Win32's TerminateProcess/ExitProcess, in turn
> NtTerminateProcess, where one waits instead on a handle to the
> process.

TerminateProcess() is documented to perform error checking and then to 
schedule asynchronous termination of the specified process.  I would not 
be surprised if the asynchronous termination applies even when 
GetCurrentProcess() is used to specify the process to terminate, but I 
would likewise not be surprised if TerminateProcess() has special 
handling for this.  I agree that calls to TerminateProcess() might 
return before the calling thread/process is terminated.  I have not 
tried to verify this behavior though.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms686714%28v=vs.85%29.aspx

The MSDN documentation for TerminateThread() does not state that the 
termination is carried out asynchronously, but I would not be surprised 
if that is the case.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms686717%28v=vs.85%29.aspx

I would be *very* surprised if it is possible for ExitProcess() and 
ExitThread() to return (unless the thread is being suspended and its 
context manipulated by another process/thread).  The MSDN docs for these 
do not mention any possibility of return.  In addition, the ExitThread() 
documentation explicitly states that Windows manages serialization of 
calls to ExitProcess() and ExitThread().

<quote>
The ExitProcess, ExitThread, CreateThread, CreateRemoteThread functions, 
and a process that is starting (as the result of a CreateProcess call) 
are serialized between each other within a process. Only one of these 
events can happen in an address space at a time.
</quote>

http://msdn.microsoft.com/en-us/library/windows/desktop/ms682659%28v=vs.85%29.aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/ms682658%28v=vs.85%29.aspx

I read that quote as supporting my assertion that the observed behavior 
is a defect in Windows.  It appears Windows is failing to serialize the 
calls appropriately.

Tom.


--
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



More information about the Cygwin mailing list