On 3/11/11 1:45 AM, Ingo Molnar wrote:
>
> * Chet Ramey wrote:
>
>>> So the above trace is one that my patch would have handled correctly
>>> (since it has no EINTR). Maybe a combination of the two approaches
>>> would work even better?
>>
>> I installed what is essentially the union of your cha
* Chet Ramey wrote:
> > So the above trace is one that my patch would have handled correctly
> > (since it has no EINTR). Maybe a combination of the two approaches
> > would work even better?
>
> I installed what is essentially the union of your changes and mine. Thanks
> for everyone's help w
> So the above trace is one that my patch would have handled correctly
> (since it has no EINTR). Maybe a combination of the two approaches
> would work even better?
I installed what is essentially the union of your changes and mine. Thanks
for everyone's help with this.
Chet
--
``The lyf so s
On 3/7/11 11:52 AM, Linus Torvalds wrote:
> On Mon, Mar 7, 2011 at 8:24 AM, Linus Torvalds
> wrote:
>>
>> and I think one reason why the race is hard to get rid of is simply
>> that system call return is _the_ common point of signal handling in
>> UNIX (technically, obviously any return to user sp
On 3/7/11 12:42 PM, Oleg Nesterov wrote:
> On 03/07, Chet Ramey wrote:
>>
>>> On 03/07, Chet Ramey wrote:
*** 3090,3096
--- 3099,3107
waitpid_flags |= WNOHANG;
}
+ waiting_for_child++;
pid = WAITPID (-1, &status, waitpid_flags)
On 03/07, Chet Ramey wrote:
>
> > On 03/07, Chet Ramey wrote:
> > >
> > > *** 3090,3096
> > > --- 3099,3107
> > > waitpid_flags |= WNOHANG;
> > > }
> > >
> > > + waiting_for_child++;
> > > pid = WAITPID (-1, &status, waitpid_flags);
> >
> > OK, and what
On Mon, Mar 7, 2011 at 8:45 AM, Chet Ramey wrote:
>
> The one thing that jumps out at me here is the number of signal-handling
> system calls. wait_sigint_handler gets installed and removed as the
> SIGINT handler a lot. I wonder if we would see an improvement if I
> used a global SIGINT handler
> On 03/07, Chet Ramey wrote:
> >
> > > So I don't think my patch is really doing what it _intends_ to do.
> >
> > Let's take a step back and approach this a different way. Instead of
> > trying to intuit whether or not the child did anything with the SIGINT,
> > let's try to make the race conditi
> The trace I just captured looks like this:
>
> 08:12:54.424327 clone(child_stack=0,
> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
> child_tidptr=0x7fdf2ad8e9f0) = 15397
> 08:12:54.424394 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> 08:12:54.424432 rt_sigprocmask(SIG_BLOCK, [CH
On Mon, Mar 7, 2011 at 8:24 AM, Linus Torvalds
wrote:
>
> and I think one reason why the race is hard to get rid of is simply
> that system call return is _the_ common point of signal handling in
> UNIX (technically, obviously any return to user space, but there are
> no appreciable interrupts etc
On 03/07, Chet Ramey wrote:
>
> > So I don't think my patch is really doing what it _intends_ to do.
>
> Let's take a step back and approach this a different way. Instead of
> trying to intuit whether or not the child did anything with the SIGINT,
> let's try to make the race condition smaller.
O
On Mon, Mar 7, 2011 at 7:52 AM, Chet Ramey wrote:
>
> Let's take a step back and approach this a different way. Instead of
> trying to intuit whether or not the child did anything with the SIGINT,
> let's try to make the race condition smaller.
I can still easily see the porblem. I think your pa
> So I don't think my patch is really doing what it _intends_ to do.
Let's take a step back and approach this a different way. Instead of
trying to intuit whether or not the child did anything with the SIGINT,
let's try to make the race condition smaller.
The following patch is a very small chan
On 3/1/11 1:28 AM, Linus Torvalds wrote:
> A real interactive program that uses ^C (like an editor) isn't
> actually ever going to see a SIGINT _at_all_, since it will set the
> tty state to -isig, and actually read the ^C as the character '\003'
> rather than have any SIGINT issues). I dunno.
I
On Mon, Feb 28, 2011 at 6:20 PM, Chet Ramey wrote:
>
> The patch looks good. I'll take a closer look and probably produce a
> patch for bash-4.2 based on it. Thanks for taking a look.
So I think that Oleg Nesterov is correct in that the -1 return with
errno==EINTR will never actually trigger, b
On 2/11/11 6:35 PM, Linus Torvalds wrote:
> On Fri, Feb 11, 2011 at 1:30 PM, Linus Torvalds
> wrote:
>>
>> The other case is that the child process was quick and already exited.
>> You get ^C, but the child never did. When you do the waitpid(), you'll
>> never get the EINTR, because there was no a
On 2/11/11 4:00 PM, Oleg Nesterov wrote:
> I already tried to discuss this, but you didn't reply ;) See
> http://www.mail-archive.com/bug-bash@gnu.org/msg08528.html
>
> So, if I understand correctly, you mean that
>
> #!/bin/sh
>
> interactive_application
>
> echo DONE
>
> s
On 2/11/11 12:27 PM, Oleg Nesterov wrote:
> On 02/11, Illia Bobyr wrote:
>>
>> Do we really need to check wait_sigint_received here?
>> If the child exits because of SIGINT was indeed received all the
>> processes on the same terminal will also receive it.
>
> Only if SIGINT was sent to pgrp (like
On 2/9/11 4:57 PM, Linus Torvalds wrote:
> On Wed, Feb 9, 2011 at 1:18 PM, Bob Proulx wrote:
>>
>> Since the exit status of /bin/true is ignored then I think that test
>> case is flawed. I think at the least needs to check the exit status
>> of the /bin/true process.
>>
>> bash -c 'while true; d
On 2/9/11 4:39 PM, Oleg Nesterov wrote:
> If /bin/true gets SIGINT - everything is fine. With this particular
> test-case the problem is: ^C race race with true/false/whatever
> doing exit(any_exit_code). In this case the shell "ignores" the
> signal.
Yes, there is a race condition there. That's
On 2/9/11 9:50 AM, Ingo Molnar wrote:
>
> * Oleg Nesterov wrote:
>
>> That is why I provided another test-case, let me repeat it:
>>
>> #!./bash
>>
>> perl -we '$SIG{INT} = sub {exit}; sleep'
>>
>> echo "Hehe, I am going to sleep after ^C"
>> sleep 100
>
> This reliably repr
On 2/9/11 9:18 AM, Oleg Nesterov wrote:
>> Consider a script that runs
>> emacs, then does other processing when emacs completes. Emacs uses SIGINT
>> internally to interrupt editing commands, but handles it and does not exit
>> as a result. Since emacs is run from a script, and job control is n
On 2/8/11 7:11 PM, Ingo Molnar wrote:
> Could you try the reproducer please?
>
> Once you run it, try to stop it via Ctrl-C, and try to do this a couple of
> times.
>
> Do you consider it normal that it often takes 2-3 Ctrl-C attempts to
> interrupt that
> script, that it is not possible to s
On 2/8/11 3:09 PM, Oleg Nesterov wrote:
> On 02/08, Chet Ramey wrote:
>>
>> On 2/8/11 1:21 PM, Oleg Nesterov wrote:
>>> Hello,
>>>
>>> We believe that the non-interactive bash doesn't handle CTRL-C
>>> correctly, please look into the attached thread from lkml for
>>> more details.
>>
>> Read http:/
On 02/11, Linus Torvalds wrote:
>
> @@ -2424,6 +2425,18 @@ wait_for (pid)
> sigaction (SIGCHLD, &oact, (struct sigaction *)NULL);
> sigprocmask (SIG_SETMASK, &chldset, (sigset_t *)NULL);
> # endif
> + /* If the waitchld returned EINTR, and the shell got a SIGINT,
> +
On Fri, Feb 11, 2011 at 1:30 PM, Linus Torvalds
wrote:
>
> The other case is that the child process was quick and already exited.
> You get ^C, but the child never did. When you do the waitpid(), you'll
> never get the EINTR, because there was no actual wait.
Ok, so here's a suggested patch. It t
On Fri, Feb 11, 2011 at 1:16 PM, Chet Ramey wrote:
>
> In the meantime, read Martin Cracauer's description of the issue.
> http://www.cons.org/cracauer/sigint.html.
This is now the second time in the thread that this has been quoted,
but bash doesn't even FOLLOW the recommendations in that web-pa
On 02/11, Chet Ramey wrote:
>
> In the meantime, read Martin Cracauer's description of the issue.
> http://www.cons.org/cracauer/sigint.html.
I did.
OK, OK, I didn't ;) I stopped the reading immediately after I started
to think I understand why you sent me this link.
Oleg.
On Fri, Feb 11, 2011 at 12:21 PM, Chet Ramey wrote:
>
> You do realize that this case is indistinguishable from the original
> scenario in question: the child gets the SIGINT, handles it, and exits
> successfully (or not). Have you actually not followed the discussion?
Umm. I'm the one who broug
On 2/11/11 4:00 PM, Oleg Nesterov wrote:
> On 02/11, Chet Ramey wrote:
>>
>> You do realize that this case is indistinguishable from the original
>> scenario in question: the child gets the SIGINT, handles it, and exits
>> successfully (or not).
>
> I already tried to discuss this, but you didn't
On 02/11, Chet Ramey wrote:
>
> You do realize that this case is indistinguishable from the original
> scenario in question: the child gets the SIGINT, handles it, and exits
> successfully (or not).
I already tried to discuss this, but you didn't reply ;) See
http://www.mail-archive.com/bug-bash@g
On 2/11/11 3:01 PM, Linus Torvalds wrote:
> On Fri, Feb 11, 2011 at 8:57 AM, Illia Bobyr
> wrote:
>> On 2/9/2011 3:57 PM, Linus Torvalds wrote:
>>>
>>> Here's the scenario:
>
> I'll quote the scenario again, because you clearly didn't bother to read it.
>
> Please _READ_ it this time before you
On Fri, Feb 11, 2011 at 8:57 AM, Illia Bobyr
wrote:
> On 2/9/2011 3:57 PM, Linus Torvalds wrote:
>>
>> Here's the scenario:
I'll quote the scenario again, because you clearly didn't bother to read it.
Please _READ_ it this time before you answer, ok?
>> - wait_for() sets wait_sigint_received
On 02/11, Illia Bobyr wrote:
>
> Do we really need to check wait_sigint_received here?
> If the child exits because of SIGINT was indeed received all the
> processes on the same terminal will also receive it.
Only if SIGINT was sent to pgrp (like ^C sends SIGTERM to the
foreground process group).
On 2/9/2011 3:57 PM, Linus Torvalds wrote:
> [...]
> The problem is that
> 'set_job_status_and_cleanup()' does that
>
> if (wait_sigint_received&& (WTERMSIG (child->status) == SIGINT)&& ..
>
> which just looks totally buggy and racy. There's even a comment about
> it in the bash source code,
On Wed, Feb 9, 2011 at 1:18 PM, Bob Proulx wrote:
>
> Since the exit status of /bin/true is ignored then I think that test
> case is flawed. I think at the least needs to check the exit status
> of the /bin/true process.
>
> bash -c 'while true; do /bin/true || exit 1; done'
The "|| exit 1" doe
On Wed, Feb 9, 2011 at 08:53, Ingo Molnar wrote:
>
> * Michael Witten wrote:
>
>> On Mon, Feb 7, 2011 at 07:08, Oleg Nesterov wrote:
>> > Now that it is clear what happens, the test-case becomes even more
>> > trivial:
>> >
>> > bash-4.1$ ./bash -c 'while true; do /bin/true; done'
>> >
On 02/09, Bob Proulx wrote:
>
> Oleg Nesterov wrote:
>
> > That is why I provided another test-case, let me repeat it:
>
> Sorry but I missed seeing that the first time through or I would have
> commented.
>
> > #!./bash
> > perl -we '$SIG{INT} = sub {exit}; sleep'
> > echo "Hehe, I am
On 02/09, Bob Proulx wrote:
>
> Ingo Molnar wrote:
> > Could you try the reproducer please?
> >
> > Once you run it, try to stop it via Ctrl-C, and try to do this a
> > couple of times.
>
> I was not able to reproduce your problem using your (I believe to be
> slightly incorrect) test case:
>
> b
On 02/09, Bob Proulx wrote:
>
> Oleg Nesterov wrote:
> > Bob Proulx wrote:
> > > Is the behavior you observe any different for this case?
> > > $ bash -c 'while true; do /bin/true || exit 1; done'
> > > Or different for this case?
> > > $ bash -e -c 'while true; do /bin/true; done'
> >
> > The
Oleg Nesterov wrote:
> That is why I provided another test-case, let me repeat it:
Sorry but I missed seeing that the first time through or I would have
commented.
> #!./bash
> perl -we '$SIG{INT} = sub {exit}; sleep'
> echo "Hehe, I am going to sleep after ^C"
> sleep 100
Ingo Molnar wrote:
> Could you try the reproducer please?
>
> Once you run it, try to stop it via Ctrl-C, and try to do this a
> couple of times.
I was not able to reproduce your problem using your (I believe to be
slightly incorrect) test case:
bash -c 'while true; do /bin/true; done'
It was
Oleg Nesterov wrote:
> Bob Proulx wrote:
> > Is the behavior you observe any different for this case?
> > $ bash -c 'while true; do /bin/true || exit 1; done'
> > Or different for this case?
> > $ bash -e -c 'while true; do /bin/true; done'
>
> The same.
I expected that to behave differently
* Oleg Nesterov wrote:
> That is why I provided another test-case, let me repeat it:
>
> #!./bash
>
> perl -we '$SIG{INT} = sub {exit}; sleep'
>
> echo "Hehe, I am going to sleep after ^C"
> sleep 100
This reliably reproduces the (formerly sporadic) script Ctrl-C bug
On 02/08, Chet Ramey wrote:
>
> On 2/8/11 7:11 PM, Ingo Molnar wrote:
> >
> > Oleg also found another simple testcase i think - and Thomas (Cc:-ed)
> > reported
> > similar Ctrl-C problems with Bash as well.
>
> I tried to reproduce it and wasn't able to. I use Mac OS X.
Strange, but I know noth
On 02/08, Chet Ramey wrote:
>
> On 2/8/11 4:17 PM, Oleg Nesterov wrote:
>
> > Once again. If bash gets ^C and at the same time the current foreground
> > child exits normally (either because this jctl signal races with exit()
> > or because the child hooks SIGINT and exits after that) SIGINT is los
On 2/8/11 7:11 PM, Ingo Molnar wrote:
>
> * Chet Ramey wrote:
>
>> On 2/8/11 4:17 PM, Oleg Nesterov wrote:
>>
>>> Once again. If bash gets ^C and at the same time the current foreground
>>> child exits normally (either because this jctl signal races with exit()
>>> or because the child hooks SIG
* Chet Ramey wrote:
> On 2/8/11 4:17 PM, Oleg Nesterov wrote:
>
> > Once again. If bash gets ^C and at the same time the current foreground
> > child exits normally (either because this jctl signal races with exit()
> > or because the child hooks SIGINT and exits after that) SIGINT is lost.
> >
On 2/8/11 4:17 PM, Oleg Nesterov wrote:
> Once again. If bash gets ^C and at the same time the current foreground
> child exits normally (either because this jctl signal races with exit()
> or because the child hooks SIGINT and exits after that) SIGINT is lost.
>
> set_job_status_and_cleanup() in
On 02/08, Bob Proulx wrote:
>
> Oleg Nesterov wrote:
> > $ sh -c 'while true; do /bin/true; done'
>
> Be careful that 'sh' is actually 'bash'. It isn't on a lot of
> machines. To ensure that you are actually running bash you should
> call bash explicitly. (At least we can't assume you are ru
Oleg Nesterov wrote:
> $ sh -c 'while true; do /bin/true; done'
Be careful that 'sh' is actually 'bash'. It isn't on a lot of
machines. To ensure that you are actually running bash you should
call bash explicitly. (At least we can't assume you are running bash
otherwise.)
Is the behavior
On 02/08, Chet Ramey wrote:
>
> On 2/8/11 1:21 PM, Oleg Nesterov wrote:
> > Hello,
> >
> > We believe that the non-interactive bash doesn't handle CTRL-C
> > correctly, please look into the attached thread from lkml for
> > more details.
>
> Read http://www.cons.org/cracauer/sigint.html
oooh... it
)
by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id p0SIU4Nr010577;
Fri, 28 Jan 2011 13:30:06 -0500
Received: from elvis.elte.hu ([157.181.1.14])
by mx3.mail.elte.hu with esmtp (Exim)
id 1Pit4x-zE-Ks
from ; Fri, 28 Jan 2011 19:30:00 +0100
Received:
On 2/8/11 1:21 PM, Oleg Nesterov wrote:
> Hello,
>
> We believe that the non-interactive bash doesn't handle CTRL-C
> correctly, please look into the attached thread from lkml for
> more details.
Read http://www.cons.org/cracauer/sigint.html and see if you still
feel the same way.
Chet
--
``The
54 matches
Mail list logo
