This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)

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

>>> 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

   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);en-us;176906


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]