From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1926 invoked by alias); 26 May 2011 02:20:51 -0000 Received: (qmail 1916 invoked by uid 22791); 26 May 2011 02:20:50 -0000 X-SWARE-Spam-Status: No, hits=-0.7 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from crispin.apple.com (HELO mail-out.apple.com) (17.151.62.50) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 26 May 2011 02:20:36 +0000 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LLS0085K6HOLBT0@mail-out.apple.com> for cygwin@cygwin.com; Wed, 25 May 2011 19:20:35 -0700 (PDT) Received: from jdong-mac-tower.apple.com (jdong-mac-tower.apple.com [17.213.40.128]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 07.8C.18996.3F8BDDD4; Wed, 25 May 2011 19:20:35 -0700 (PDT) Subject: Re: Cygwin 1.7.x on Windows 7: Exit statuses of Win32 executables are sometimes wrong From: John Dong In-reply-to: <20110525141942.GA22790@ednor.casa.cgf.cx> Date: Thu, 26 May 2011 02:20:00 -0000 Message-id: <6D93D09A-BA8D-4975-A17C-81A5DC4BDF91@apple.com> References: <0C817B08-1920-43DB-B9A0-26E4B2E362EA@apple.com> <4DDD0F23.5000807@sidefx.com> <20110525141942.GA22790@ednor.casa.cgf.cx> To: cygwin@cygwin.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: 2011-05/txt/msg00377.txt.bz2 Hi Chris, It's nice to hear from Edward that we're not the only ones to notice this behavior. Of course, patches would be nice, and I would be interested in digging in into this if someone familiar with Cygwin's codebase would be willing to enlighten me as to the codepath for grabbing Win32 process exit codes and how it differs from "Cygwin processes". John On May 25, 2011, at 7:19 AM, Christopher Faylor wrote: > On Wed, May 25, 2011 at 10:16:03AM -0400, Edward Lam wrote: >> On 29/04/2011 2:35 PM, John Dong wrote: >>> Reproducing this seems nondeterministic -- sometimes I can get it to >>> happen in 5 minutes, other times it takes overnight. I've tried using >>> a different shell (like dash), but it doesn't make a difference, >>> leading me to suspect this to be a lower-level issue within the >>> Cygwin DLL. It also seems to not happen for non-zero exit codes (e.g. >>> checking that exiter.exe 1 returns 1 always seems to succeed), though >>> I'm not 100% confident that I've tested this thoroughly enough. >>> >>> Again, I've not been able to reproduce this under Windows XP using >>> any version of Cygwin, but I have been able to reproduce it on both >>> 32-bit and 64-bit Windows 7. I'm not running anything special on this >>> machine -- it's a fresh install of Windows 7 Professional, just with >>> Cygwin installed. >> >> FWIW, we've been running into this as well. It appears to NOT be a >> problem with Cygwin 1.5 on Windows 7. It only started happening on >> Cygwin 1.7. As a result, we haven't had a reliable Windows 7 build >> machine for a while now because we use a Cygwin gmake process that >> compiles with MSVC. > > As always: http://cygwin.com/acronyms#PTC > > -- > 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 > -- 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