Mail Archives: cygwin/2004/09/15/13:00:20
On Wed, Sep 15, 2004 at 12:35:14PM -0400, Pierre A. Humblet wrote:
>Christopher Faylor wrote:
>> On Tue, Sep 14, 2004 at 11:01:23PM -0400, Bogdan Vacaliuc wrote:
>> >Ok. Running 09/14/04 snapshot is looking *good* so far. I stopped the
>> >test script at 150 passes.
>> >
>> >I'm starting my configure/build/redo test and will let that run
>> >overnight. I'll check in tomorrow AM and report on that. 1 successful
>> >configure/build so far.
>>
>> That points to a problem with bash, then, not cygwin.
>>
>> If we can confirm this then we should probably notify the bash
>> maintainer.
>
>He might be interested by the attachment below, obtained from
>the bashstrace in http://cygwin.com/ml/cygwin/2004-09/msg00626.html
>
>fgrep ' 1696 ' bashstrace | grep '= fork\|wait4: call' > bashstrace_grep.txt
>
>Every fork is followed by a wait, except the one that leads to trouble.
>Somehow bash draws conclusions about its status without doing a wait.
>Pid reuse shouldn't be the root cause of this behavior.
But, the fork previous to the last fork had been seen 5 times previously and
the gap between the last occurrence of pid 456 was 7 which is greater than
the 4 pids that cygwin holds in check to prevent duplication.
Here's a useless table showing the occurrence of pids:
PID PREV SEEN PID PREV SEEN PID PREV SEEN PID PREV SEEN
2308 -1 0 1432 6 1 2444 -1 0 2444 6 2
2036 -1 0 2308 6 2 1432 6 3 500 -1 0
1488 -1 0 2036 6 2 1488 10 3 456 6 4
456 -1 0 1488 6 2 2308 6 4 1488 5 5
2104 -1 0 456 6 2 928 5 1 2104 21 3
1432 -1 0 2104 6 2 2444 5 1 1432 8 5
2308 6 1 1432 6 2 2292 -1 0 316 -1 0
2036 6 1 652 -1 0 456 14 3 2296 -1 0
1488 6 1 2308 7 3 1432 7 4 888 -1 0
456 6 1 1744 -1 0 1488 7 4 456 7 5
2104 6 1 928 -1 0 2308 7 5 2016 -1 0
PID is the pid produced by fork.
PREV is how many forks ago we'd previously seen this same pid (-1 means
never).
SEEN is how many times we've seen this pid.
There doesn't seem to be anything especially unique about pid 456 (the
problematic one), at least from this table. But, it sure is fun analyzing
the data like bash was a black box... It does seem like the correct number
of pids to hold is probably 8, though so, maybe the temporary change to
cygwin is a keeper.
>Also according the the following comment in bash code, the Cygwin style of
>pid reuse should be no problem:
>#if defined (RECYCLES_PIDS)
> /* LynxOS, for one, recycles pids very quickly -- so quickly
> that a new process may have the same pid as the last one
> created. This has been reported to fix the problem. */
IIRC, bash keeps some kind of cache of pids which it has recently seen and
incorrectly decides not to wait for pids in some cases. The RECYCLES_PIDS
define turned out not to be foolproof. I had, at one point, turned off
the code in cygwin which works around this problem when it looked like
bash had a fix but the problem still manifested.
cgf
--
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/
- Raw text -