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: "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
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 and 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]
> [2]
> [3]
> [4]

Sigh, I wish I had more time to track this down...
      |\      _,,,---,,_ |
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:
Problem reports:

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