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 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 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 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 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 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 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} =
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?
> > >
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
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
&g
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
our ctrl-c input)
- Read/poll/select system calls (so you know when your terminal receives the
input).
- Signals sent/delivered
Some of these are already instrumented in the mainline kernel, so you might get
away without the input subsystem instrumentation.
If I had to take a wild guess, my bet
14 matches
Mail list logo
