Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
From: "Bogdan Vacaliuc" <bvacaliuc AT ngit DOT com>
To: <cygwin AT cygwin DOT com>
Subject: RE: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)
Date: Tue, 14 Sep 2004 02:45:11 -0400
Organization: NGI Technology, LLC
Message-ID: <01af01c49a26$625a5b20$0b03a8c0@lithium>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
In-Reply-To: <20040914022552.GC26109@trixie.casa.cgf.cx>
Content-Transfer-Encoding: 8bit

Chris, Pierre,

> I was thinking the same thing but AFAIK, ash doesn't have the 
> pid recycling problem.

In my failure cases, configure is run under bash.

I have also captured (finally?) an strace under the ~current cygwin (attached).  The details are largely the same as Peter's last
attachment, to which Igor remarked "FWIW, expr.exe does seem to exit with the right exit code, but is later zombified, which doesn't
sound quite right."

Actually, its ok for it to be zombified, because the parent didn't happen to be waiting for the child at the time that the child
exited.

>>> Pierre's observation that error text is output by the parent shell *before* the expr command even executes was an inspiration.

So it seems like the parent shell decides its going to exit after forking but before waiting on the expr process.  This is
consistent across all my straces as well as Peter's.  In my attached trace, this is between lines 582 and 750; I also noticed the
following:

   84 16461744 [main] bash 1048 close: close (1)
 1378 16461829 [main] bash 2028 close: close (1)

On line 725 and 726.  By the time my trace got to line 750, the parent shell had stated to output the error text (53 characters in
my case).  I have another trace that exhibits this too.  Peter's trace does not have this.

In my trace (not Peter's) there are also some lines like:

  324 16458452 [main] bash 1048 fhandler_base::set_no_inheritance: DuplicateHandle failed, The parameter is incorrect.
  237 16458689 [main] bash 1048 fhandler_base::set_close_on_exec: set close_on_exec for /dev/console to 1

In the time between the fork and the beginning of the error write, but this is not unique to the trace and it was handled apparently
ok previously in the script.


> Wasn't there a registry value that controlled how pids were 
> allocated? I can't find anything appropriate in google.

I looked for something about this in M$ knowledge base.  I didn't find that, but I found this:

"BUG: Registry access from multiple threads might fail" (WinNT, Win2K)
http://support.microsoft.com/default.aspx?scid=kb;en-us;176906


-bogdan


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/