This is the mail archive of the
mailing list for the Cygwin project.
Re: Bash wait indefinitely
- From: Antoine Labour <antoine dot labour at m4x dot org>
- To: Nicholas Wourms <nwourms at myrealbox dot com>
- Cc: cygwin at cygwin dot com
- Date: Mon, 01 Dec 2003 12:00:27 -0800
- Subject: Re: Bash wait indefinitely
- References: <firstname.lastname@example.org> <3FC7AC79.email@example.com>
Nicholas Wourms wrote:
I'm running in concurrences 5 complex bash batch, and sometimes (2
3) one or more (very rarely) batch stop to do something. I've put a
trace to see where is the problem, but seems rarely arrived at the
I've also tried to use strace tool, but strace hang rapidly.
For the last few weeks I've been experiencing the same, and the
offenders always seem to be either bash (not ash) or make. It is
important to note that I track cygwin's CVS head, so I had chalked it up
to the on-going signal work. I've found that running deep `make`s or
running the autotools in succession (such as in the case of triggering
the AM_MAINTAINER_MODE routines) often triggers this problem for me on
my Dual Athlon MP 2400+ Win2K box :-(. I've been extremely busy working
on other things, I just grumble, kill the deadlocked process and its
children, then restart the parent. Attempting to debug gdb/strace, as
you've discovered, is quite fruitless.
Do you guys have things like command substitution in your scripts ? I
talked about a similar problem in a previous mail (but got no answer),
it certainly involves some kind of race condition with forks and pipes.
Going back to a previous version of cygwin (1.3.something) fixes that
particular problem, but exposes a lot of other pthread races. For my
part I've been able to attach gdb to the dead processes, but apart from
dumping the stack(s) traces, I couldn't tell much.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html