This is the mail archive of the
mailing list for the Cygwin project.
Re: "fork problem" debugging
"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, 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.
> 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.
> a patch (attached) that makes it print out more of the seemingly relevant
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
> 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 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". It seems that -x
would be a useful first pass at gathering data, less volume than strace?
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html