[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patch(?): bash-2.05/jobs.c loses interrupts

From: Pavel Machek
Subject: Re: Patch(?): bash-2.05/jobs.c loses interrupts
Date: Tue, 1 May 2001 18:02:22 +0200


> >     Linux-2.4.4 has a change, for which I must accept blame,
> > where fork() runs the child first, reducing unnecessary copy-on-write
> > page duplications, because the child will usually promptly do an
> > exec().  I understand this is pretty standard in most unixes.
> > 
> >     Peter Osterlund noticed an annoying side effect of this,
> > which I think is a bash bug.  He wrote:
> > 
> > > Another thing is that the bash loop "while true ; do /bin/true ; done" is
> > > not possible to interrupt with ctrl-c.
> > 
> >     I have reproduced this problem on a single CPU system.
> > I also modified my kernel to sometimes run the fork child first
> > and sometimes not.  In that case, that loop would sometimes
> > abort on a control-C and sometimes ignore it, but ignoring it
> > would not make the loop less likely to abort on another control-C.
> > I'm pretty sure the control-C was being delivered only to the child
> > due to a race condition in bash, which may be mandated by posix.
> Did you reconfigure and rebuild bash on your machine running the 2.4
> kernel, or just use a bash binary built on a previous kernel
> version?

This is nasty race condition. I do not believe you can test for it in

This might happen on 2.4.3 (occasionally) too. Kernel is permitted to
do any kind of scheduling!


> Bash has an autoconf test that will, if it detects the need to do so,
> force the job control code to synchronize between parent and child
> when setting up the process group for a new pipeline.  It may be the
> case that you have to reconfigure and rebuild bash to enable that code.
> Look for PGRP_PIPE in config.h.

I'm address@hidden "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]