[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110128165455.GA18194@elte.hu>
Date: Fri, 28 Jan 2011 17:54:55 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Tejun Heo <tj@...nel.org>
Cc: roland@...hat.com, oleg@...hat.com, jan.kratochvil@...hat.com,
linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
akpm@...ux-foundation.org, Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Thomas Gleixner <tglx@...utronix.de>,
Frédéric Weisbecker <fweisbec@...il.com>
Subject: Re: [PATCHSET] ptrace,signal: group stop / ptrace updates
Hi,
I'm hijacking this thread, to report a signal handling bug that Linux and Bash has,
and which has been there at least for 10 years since i started using SMP Linux
systems ...
It's not easy to reproduce but today i found a reproducer - maybe you guys have an
idea what's going on.
There's two very simple scripts, one calls the other in an infinite loop:
$ cat test-signal
#!/bin/bash
while true; do ./test-signal2; done
$ cat test-signal2
#!/bin/bash
true
The bug is that occasionally Ctrl-C does not get processed, and that the Ctrl-C is
'lost'. It can be reproduced here by running ./test-signal several times, and
Ctrl-C-ing it:
$ ./test-signal
^C
$ ./test-signal
^C^C
$ ./test-signal
^C
See that '^C^C' line? That is where i had to do Ctrl-C twice.
It only fails here about once every 10 times, so it's very rare. I have a stock F14
system running on that box, with the very latest .38 based kernel.
Any ideas what's going on?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists