This is the mail archive of the
mailing list for the Cygwin project.
Re: resuming backgrounded job causes hang (Cygwin 1.7.19 / Dothan 1.7GHz)
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Thu, 6 Jun 2013 17:52:00 +0200
- Subject: Re: resuming backgrounded job causes hang (Cygwin 1.7.19 / Dothan 1.7GHz)
- References: <CANi_VVc45nC55fKpCriAp6=VE+4CUvASi6Ks2nFrQ=tLktSzXg at mail dot gmail dot com> <51B05080 dot 3030106 at noprivatereply dot com> <20130606110210 dot GA13320 at calimero dot vinschen dot de>
- Reply-to: cygwin at cygwin dot com
On Jun 6 13:02, Corinna Vinschen wrote:
> On Jun 6 11:04, Seb.Th wrote:
> > Le 06/06/2013 08:25, Sumudu Fernando a Ãcrit :
> > >I'm having a weird issue in 1.7.19. As per the subject line, when I
> > >try to resume a backgrounded job, I get a hang (after bash echoes the
> > >job name). I couldn't find anything about this in the list archives,
> > >possibly because it may be limited to specific architectures (more
> > >below).
> > >
> > >simple testcase from a fresh terminal (I'm using the default mintty, with bash)
> > >$ ls | less
> > ><CTRL-Z to background less>
> > >$ fg
> > >
> > >whereupon bash echoes the job name (in my case "ls -hF --color=tty |
> > >less -r") and then nothing happens (no response to input AFAICT)
> > >
> > >Interesting things:
> > >- this only happens on my (ancient) laptop (this is why I mentioned
> > >the processor in the subject line) -- it *does not* happen on my
> > >desktop machine (which is a Q6600, nearly ancient now I suppose).
> > >- Windows task manager shows the process I tried to resume at high CPU
> > >usage, and if I kill it from there ("end process") bash recovers fine
> > >- I can open a separate cygwin terminal and see the "ls" in the output
> > >of ps. It does *not* have an "S" beside it to indicate a suspended
> > >process. "kill" does nothing, "kill -9" hangs (until I kill via task
> > >manager).
> > >
> > >I attached cygcheck output; I did get some errors (that are in the
> > >file also) but I don't know what they actually mean (if anything).
> > >
> > >FWIW, this did not happen with 1.7.17 (I skipped 1.7.18).
> > This problem seems to be very similar to the thread "Bash sub-shell
> > freezing in Midnight Commander".
> > Something went wrong after 1.7.17 (or its dependencies ?)
> This is signal stuff which is usually cgf's domain and he's not
> available for another couple of days.
> I can reproduce this, however, and I'm trying to find a fix. Stay
Ok, I found the reason for this behaviour. There was a potential
starvation problem which really only got hold on single-CPU/single
core systems. Two threads were locking a mutex and waiting for each
other. The one thread which could have resolved the problem never got
CPU time due to the locking mechanism and an extremly tight window in
which the other thread unlocked the mutex.
I fixed the problem in CVS and I've just created a new 2013-06-06 32 bit
developer snapshot, which you can find on http://cygwin.com/snapshots/,
as well as a 64 bit DLL 1.7.20-1 which I uploaded as part of the 64 bit
Please test and send feedback.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple