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)


On Wed, Sep 15, 2004 at 01:01:50PM -0400, Christopher Faylor wrote:
> 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.

I have been poking at the bash code. It keeps all the pids in
the pipelines for each job, so the number can be very large.

At any rate, trying to get status without waiting should be considered
a bug, and not a feature that Cygwin should work around.
Will someone take responsibility to notify the bash maintainer?

Pierre

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


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