Re: "fork problem" debugging

[Igor Peshansky <pechtcha at cs dot nyu dot edu>]

On Wed, 17 May 2006, Bryan D. Thomas wrote:

> I'm taking the risk of conflating several different
> issues into one.  On the other hand, this might be a
> useful synthesis to help us bottom out on "fork
> problems" so that we can turn a snapshot into a stable
> release[1]?

I've been plagued by these problems for a while (since you didn't provide
full links in your message, I don't know whether you cited my message
among them without a lot of cutting-and-pasting).  I would like to help,
but all information I have at this point is rather negative...  One
definite data point is that unloading and reloading just Cygwin1.dll (by
exiting all Cygwin processes) fixes the problem for me (until the next
time I run that resource-intensive script that reproduces the problem).

> I've been trying to figure out strace incantations.
> Hopefully someone more wizardly can help?  Is strace
> the best/only attack vector on this?

I haven't found the strace to be all that useful, especially because the
information printed in the strace doesn't reflect what's actually
happening.  The errno value is bogus (from inspecting the code).  I have a
patch (attached) that makes it print out more of the seemingly relevant
information (pretty verbosely, basically dumping the whole pinfo structure
plus printing the Windows error code) whenever a fork error occurs, but I
haven't been able to follow through on actually using that information to
debug the problem.

> In [2] Torfinn Ottesen wrote:
> > I find that my loops are OK until after about 80
> > cases, each loop increases my memory usage by about
> > 3.2 MB
> > I am aware of the following information:
> [3],[4],[5]
> > I have strace but do not know what to do with it
>
> I wonder if some strace like [6] would help?
>
> Perhaps someone could suggest a helpful "cheatsheet" of what we might
> want to focus on in strace output of these processes?
>
> If it would be helpful to run strace against the processes in the
> weather.sh fork example[7] , or in the nonsense testcase example[8]
> ...what should the command line be, and what would we be looking for in
> output?
>
> In [2], Larry Hall wrote:
> > Sounds to me like the situation you found closely mirrors the behavior
> > the MS KB article describes. I think it's worthwhile for you to
> > experiment with the workaround proposed to see if it helps. It would
> > be beneficial if you reported any results you saw back to this list.
>
> Torfinn, any luck on SharedSection parameter tweaking
> per the MS KB?

I'm not Torfinn, but I can say that I've been running with
SharedSection=2048,6144,1024 (double my original values), which had no
noticeable effect on the frequency of the fork errors (i.e., I still get
them reproducibly).

> http://sourceware.org/ml/cygwin/
> [1] 2006-05/msg00402.html
> [2] 2006-05/msg00127.html
> [3] 2006-04/msg00390.html
> [4] 2005-09/msg00945.html
> [5] http://support.microsoft.com/kb/824422
> http://sourceware.org/ml/cygwin/
> [6] 2006-05/msg00364.html
> [7] 2006-04/msg00718.html
> [8] 2006-05/msg00422.html

Sorry I couldn't be of more help, but perhaps the info printed in the
patch gives someone some idea...
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

Attachment: pinfo-dump-extra.patch
Description: Text document

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