From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13994 invoked by alias); 21 Dec 2012 19:45:03 -0000 Received: (qmail 13915 invoked by uid 22791); 21 Dec 2012 19:45:01 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from tx2ehsobe003.messaging.microsoft.com (HELO tx2outboundpool.messaging.microsoft.com) (65.55.88.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 21 Dec 2012 19:44:52 +0000 Received: from mail146-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Dec 2012 19:44:51 +0000 Received: from mail146-tx2 (localhost [127.0.0.1]) by mail146-tx2-R.bigfish.com (Postfix) with ESMTP id 735D8200BA for ; Fri, 21 Dec 2012 19:44:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.242.197;KIP:(null);UIP:(null);IPV:NLI;H:BL2PRD0512HT002.namprd05.prod.outlook.com;RD:none;EFVD:NLI X-SpamScore: -7 X-BigFish: PS-7(zzbb2dI98dI9371Izz1de0h1202h1e76h1d1ah1d2ahzz17326ah186M8275bhz32i2a8h668h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1765h1155h) Received: from mail146-tx2 (localhost.localdomain [127.0.0.1]) by mail146-tx2 (MessageSwitch) id 1356119088995281_4688; Fri, 21 Dec 2012 19:44:48 +0000 (UTC) Received: from TX2EHSMHS029.bigfish.com (unknown [10.9.14.246]) by mail146-tx2.bigfish.com (Postfix) with ESMTP id E51574C004F for ; Fri, 21 Dec 2012 19:44:48 +0000 (UTC) Received: from BL2PRD0512HT002.namprd05.prod.outlook.com (157.56.242.197) by TX2EHSMHS029.bigfish.com (10.9.99.129) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Dec 2012 19:44:48 +0000 Received: from SN2PRD0310HT002.namprd03.prod.outlook.com (157.56.234.5) by pod51010.outlook.com (10.255.233.35) with Microsoft SMTP Server (TLS) id 14.16.245.2; Fri, 21 Dec 2012 19:44:47 +0000 Message-ID: <50D4BC2C.3070507@coverity.com> Date: Fri, 21 Dec 2012 19:45:00 -0000 From: Tom Honermann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Subject: Re: Intermittent failures retrieving process exit codes References: <50C2498C.2000003@coverity.com> <50C276AC.9090301@mailme.ath.cx> <50D401EF.9040705@coverity.com> <20121221103241.GD18188@calimero.vinschen.de> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginatorOrg: coverity.com X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2012-12/txt/msg00333.txt.bz2 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(). 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. 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