X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RCVD_IN_HOSTKARMA_YE,TW_CG X-Spam-Check-By: sourceware.org X-Forefront-Antispam-Report: CIP:132.245.1.149;KIP:(null);UIP:(null);IPV:NLI;H:BLUPRD0512HT001.namprd05.prod.outlook.com;RD:none;EFVD:NLI X-SpamScore: -3 X-BigFish: PS-3(zzbb2dI98dI9371I1432Izz1de0h1202h1e76h1d1ah1d2ahzzz32i2a8h668h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1765h1155h) Message-ID: <50D4EBFE.6090309@coverity.com> Date: Fri, 21 Dec 2012 18:08:46 -0500 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 - snapshot test requested References: <50C2498C DOT 2000003 AT coverity DOT com> <50C276AC DOT 9090301 AT mailme DOT ath DOT cx> <50D401EF DOT 9040705 AT coverity DOT com> <20121221103241 DOT GD18188 AT calimero DOT vinschen DOT de> <20121221161024 DOT GA10871 AT ednor DOT casa DOT cgf DOT cx> <20121221170219 DOT GF18188 AT calimero DOT vinschen DOT de> <20121221193620 DOT GA29203 AT ednor DOT casa DOT cgf DOT cx> <50D4E144 DOT 706 AT gmail DOT com> In-Reply-To: <50D4E144.706@gmail.com> 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 AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On 12/21/2012 05:23 PM, marco atzeri wrote: > On 12/21/2012 8:36 PM, Christopher Faylor wrote: >> I tested this lightly on Windows 7 and 32-bit XP but it would be nice to >> hear if multi-threaded things like X work on other platforms too. >> >> If you test a snapshot, note that I'm still tracking down Ken Brown's >> reporte emacs regression in recent snapshots so that will still be >> broken. >> >> cgf >> > > I think the Xserver doesn't like it. > on 20121221 it freezes on start on W7/64 > no issue on 20121218 I was worried about this possibility after looking at the code changes. But, I haven't had to a chance to test adequately yet. I would expect indefinite blocking in dll_entry() may prevent unloading DLLs. For example, calls to dll_entry() for DLL_PROCESS_DETACH may get blocked. It looks to me like the changes made are insufficient to prevent the race. For example, this won't address the case where an exiting thread releases the process lock acquired in dll_entry() before a thread exiting the process acquires it in pinfo::exit(). Both threads could still end up in an ExitThread() vs ExitProcess()/TerminateProcess() race. However, this is only true for threads whose exits are not predicated upon an action taken by the process exiting thread after it has acquired the process lock in pinfo::exit(). And since the exiting thread must be the last thread of the process in order to hit the issue, this may not be a concern. I'm not sure that a general workaround for this issue is feasible for all possible threads. At least, not without hooking the Terminate* and Exit* Win32 APIs. My gut tells me that a general solution requires waiting for thread handles to be signaled, but I haven't thought it completely through yet. It looks like Chris reverted the change and checked in a new update. I haven't looked at those changes yet. 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