Hi folks,
I'm not sure if this is buggy, strange or just perfectly normal
behaviour. I was trying to write an application that does some simple
network performance polling with setitimer() and also keeps a look out
for SIGWINCH to see if the window size changes. I was interested to
find out that when I resized the window, the signal was never noticed.
Even more interesting is the fact that if I run it in strace or even
GDB to figure out what's going on, it works!
I've simplified the program to this simple test case which will show
clearly that (both on 2.4 and 2.6), SIGALRM and SIGHUP are received as
expected but that without setting a special sa_sigaction handler,
SIGWINCH and SIGCHLD don't appear to wake up sigwaitinfo(). Also,
applying a sigaction() to all signals won't change the situation unless
an sa_sigaction is set; sa_handler does not appear to change anything.
Some people mentioned blocked and ignored signals, but as can be seen in
this example, differing behaviour can be seen across signals even with
all signals blocked and ignored.
Usage:
gcc -o sigweird sigweird.c && ./sigweird
In another window, "killall -WINCH sigweird" and "killall -HUP sigweird".
Note the differing behaviour. :)
Try running "strace sigweird" or "strace -p `pidof sigweird`". Note
how the behaviour changes.
Try changing the second "#if 0" to "#if 1" to enable setting the same
signal handlers exactly for all of the signals. Note that the behaviour
does not change.
Try changing the first "#if 0" to "#if 1". Note how all signals now
appear to behave similarly, with or without strace/GDB.
CHLD and WINCH seemed to be dropped without an sa_sigaction while HUP and
ALRM seem to work as expected. This might have something to do with
their default behaviour.
Broken? Bizarre?
Simon-
Simon Kirby <[email protected]> writes:
> Hi folks,
>
> I'm not sure if this is buggy, strange or just perfectly normal
> behaviour. I was trying to write an application that does some simple
> network performance polling with setitimer() and also keeps a look out
> for SIGWINCH to see if the window size changes. I was interested to
> find out that when I resized the window, the signal was never noticed.
> Even more interesting is the fact that if I run it in strace or even
> GDB to figure out what's going on, it works!
>
> I've simplified the program to this simple test case which will show
> clearly that (both on 2.4 and 2.6), SIGALRM and SIGHUP are received as
> expected but that without setting a special sa_sigaction handler,
> SIGWINCH and SIGCHLD don't appear to wake up sigwaitinfo(). Also,
> applying a sigaction() to all signals won't change the situation unless
> an sa_sigaction is set; sa_handler does not appear to change anything.
>
> Some people mentioned blocked and ignored signals, but as can be seen in
> this example, differing behaviour can be seen across signals even with
> all signals blocked and ignored.
The SIGWINCH and SIGCHLD signals are not generated if their
disposition is set to SIG_DFL. I believe SIGCONT and SIGURG also
behave similarly. If you want to see them from your application, you
have to establish a (potentially empty) signal handler.
Phil.
On Tue, Sep 27, 2005 at 06:19:24PM -0700, Philippe Troin wrote:
> The SIGWINCH and SIGCHLD signals are not generated if their
> disposition is set to SIG_DFL. I believe SIGCONT and SIGURG also
> behave similarly. If you want to see them from your application, you
> have to establish a (potentially empty) signal handler.
Ok, and this is what I did in the example; however, is it expected that
it does not help to set a handler in sa_handler and call sigaction()?
In fact, it does not matter what sa_handler is set to (it can still be
SIG_IGN), but sa_sigaction must point to a valid handler.
Simon-
Simon Kirby <[email protected]> writes:
> On Tue, Sep 27, 2005 at 06:19:24PM -0700, Philippe Troin wrote:
>
> > The SIGWINCH and SIGCHLD signals are not generated if their
> > disposition is set to SIG_DFL. I believe SIGCONT and SIGURG also
> > behave similarly. If you want to see them from your application, you
> > have to establish a (potentially empty) signal handler.
>
> Ok, and this is what I did in the example; however, is it expected that
> it does not help to set a handler in sa_handler and call sigaction()?
> In fact, it does not matter what sa_handler is set to (it can still be
> SIG_IGN), but sa_sigaction must point to a valid handler.
As long as sa_handler (or sa_sigaction) is not SIG_DFL (which is NULL
on linux).
Phil.
On Wed, Sep 28, 2005 at 08:30:06AM -0700, Philippe Troin wrote:
> As long as sa_handler (or sa_sigaction) is not SIG_DFL (which is NULL
> on linux).
No, this is not the case. This is why I provided the example. I cannot
get it to work with sa_handler.
Simon-