This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: "fork problem" debugging
On Thu, 18 May 2006, Bryan D. Thomas wrote:
> "Igor Peshansky" wrote:
> > 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 didn't cite your message[1], though it was one of the sources of the
> suggestion to factor out antivirus and firewall software. Thanks for that.
> Also, I will use full links from now on, since my mail software seems to
> wrap the lines haphazardly no matter how I try to trim them.
Actually, I was referring to
<http://cygwin.com/ml/cygwin/2005-12/msg00817.html>...
FYI, the above is shortest real link you can give to a mailing list
archived message.
> > 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).
>
> This workaround is effective for me, also.
Well, the fact that only Cygwin is unloaded and reloaded pretty much seems
to exclude any pure Windows cause, doesn't it?
> > a patch (attached) that makes it print out more of the seemingly
> > relevant information
>
> If I understand the patch correctly, it changes fork.cc and pinfo.cc in
> winsup/cygwin. Those who wish to use it would download the winsup-src
> snapshot package, apply this patch, then compile a new cygwin1.DLL
> something like [2]?
Exactly. Once you've built a version of cygwin1.dll from CVS, apply the
patch and rebuild.
> > 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).
>
> Thank you for this data point. Hopefully we can look elsewhere with
> confidence, at least for the most common reason(s).
>
> When I was looking for your message, I found another from Dave Korn[3]
> in which he suggested using -x option to bash to see details of the
> failure. This is also used in what I called "nonsense testcase"[4]. It
> seems that -x would be a useful first pass at gathering data, less
> volume than strace?
Umm, -x will only show you which command fails, but not the way in which
it fails. As I said above, I don't even think strace has enough info to
debug this.
> [1] http://sourceware.org/ml/cygwin/2006-04/msg00127.html
> [2] http://sourceware.org/ml/cygwin/2006-05/msg00262.html
> [3] http://sourceware.org/ml/cygwin/2006-04/msg00125.html
> [4] http://sourceware.org/ml/cygwin/2006-05/msg00422.html
Sigh, I wish I had more time to track this down...
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"
--
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/