From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9626 invoked by alias); 21 Dec 2012 23:09:05 -0000 Received: (qmail 9615 invoked by uid 22791); 21 Dec 2012 23:09:04 -0000 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 Received: from va3ehsobe003.messaging.microsoft.com (HELO va3outboundpool.messaging.microsoft.com) (216.32.180.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 21 Dec 2012 23:08:57 +0000 Received: from mail61-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Dec 2012 23:08:54 +0000 Received: from mail61-va3 (localhost [127.0.0.1]) by mail61-va3-R.bigfish.com (Postfix) with ESMTP id B62A1360114 for ; Fri, 21 Dec 2012 23:08:54 +0000 (UTC) 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) Received: from mail61-va3 (localhost.localdomain [127.0.0.1]) by mail61-va3 (MessageSwitch) id 1356131332631771_17009; Fri, 21 Dec 2012 23:08:52 +0000 (UTC) Received: from VA3EHSMHS041.bigfish.com (unknown [10.7.14.252]) by mail61-va3.bigfish.com (Postfix) with ESMTP id 967B1160218 for ; Fri, 21 Dec 2012 23:08:52 +0000 (UTC) Received: from BLUPRD0512HT001.namprd05.prod.outlook.com (132.245.1.149) by VA3EHSMHS041.bigfish.com (10.7.99.51) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Dec 2012 23:08:52 +0000 Received: from BY2PRD0310HT004.namprd03.prod.outlook.com (157.56.236.5) by pod51010.outlook.com (10.255.215.162) with Microsoft SMTP Server (TLS) id 14.16.245.2; Fri, 21 Dec 2012 23:08:51 +0000 Message-ID: <50D4EBFE.6090309@coverity.com> Date: Fri, 21 Dec 2012 23:09: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 - snapshot test requested References: <50C2498C.2000003@coverity.com> <50C276AC.9090301@mailme.ath.cx> <50D401EF.9040705@coverity.com> <20121221103241.GD18188@calimero.vinschen.de> <20121221161024.GA10871@ednor.casa.cgf.cx> <20121221170219.GF18188@calimero.vinschen.de> <20121221193620.GA29203@ednor.casa.cgf.cx> <50D4E144.706@gmail.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@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/msg00337.txt.bz2 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