public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: John Dong <jdong@apple.com>
To: cygwin@cygwin.com
Subject: Re: Cygwin 1.7.x on Windows 7: Exit statuses of Win32 executables are sometimes wrong
Date: Thu, 26 May 2011 02:20:00 -0000	[thread overview]
Message-ID: <6D93D09A-BA8D-4975-A17C-81A5DC4BDF91@apple.com> (raw)
In-Reply-To: <20110525141942.GA22790@ednor.casa.cgf.cx>

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

  reply	other threads:[~2011-05-26  2:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-29 20:01 John Dong
2011-04-30 11:30 ` Edward McGuire
2011-04-30 13:23   ` John Dong
2011-05-02 17:18     ` John Dong
2011-05-10 17:22 ` John Dong
2011-05-25 14:16 ` Edward Lam
2011-05-25 14:20   ` Christopher Faylor
2011-05-26  2:20     ` John Dong [this message]
2011-05-26  5:47       ` Christopher Faylor
2011-05-26  6:02 ` Corinna Vinschen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6D93D09A-BA8D-4975-A17C-81A5DC4BDF91@apple.com \
    --to=jdong@apple.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).