SIGALRM can't be delivered after longjmp from handler?

SIGALRM can't be delivered after longjmp from handler?

[Peter M. Jansson]

I wrote the example that follows to illustrate what I think is a
problem with signal delivery.  If this program works, then it should run
in 5 cycles; the first 2 end with the "Timed out" message, while the
last 3 end with the "Wait interrupted" message.  On my PowerMac 7200
running 2.2.15pre3, I get 2 "Timed out" cycles, one "Wait interrupted"
cycle, and then two more "Timed out" cycles.  What I think is going on
is that, once the SIGALRM handler executes the longjmp, no further
SIGALRM signals are delivered to the process -- I don't know if this is
because the signals aren't delivered, or because the setitimer call
isn't working.  I've observed this example to run correctly on BSD/OS,
IRIX, and Solaris, and seen it fail on LinuxPPC and Linux x86.

Anyone seen this, and possibly know of a fix or workaround?

Pete.

-------------------------------

#include <signal.h>
#include <setjmp.h>
#include <sys/time.h>
#include <stdio.h>

static jmp_buf env;
static unsigned int count = 0;

static void
interrupt()
{
        printf ("Interrupt: %d\n", count);
        if (count > 2)
                longjmp(env, 1);
}

main ()
{
        struct timeval tv;
        struct itimerval it, oit;

        while (count++ < 5) {
                printf("Cycle %d\n", count);

                if (setjmp(env)) {
                        printf ("Wait interrupted\n");
                } else {
                        if (signal(SIGALRM, interrupt) == SIG_ERR)
                                perror("signal");
                        getitimer(ITIMER_REAL, &oit);
                        timerclear(&it.it_interval);
                        it.it_value.tv_sec = 2;
                        it.it_value.tv_usec = 16665;
                        if (setitimer(ITIMER_REAL, &it, &oit) < 0)
                        perror("tick");
                        printf ("Set timer; waiting...\n");
                        tv.tv_sec = 5;
                        tv.tv_usec = 0;
                        select(0, NULL, NULL, NULL, &tv);
                        printf ("Timed out\n");
                }
        }
}

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SIGALRM can't be delivered after longjmp from handler?

[Sriranga Veeraraghavan]

For other signals like SEGV and BUS and INTR, I had to re-enable the
signal by calling signal() after longjmp as specified in the signal(2)
manpage for Linux:

"Unlike on BSD systems, signals under Linux are reset to their default
behavior when raised.  However, if you include <bsd/signal.h> instead
of <signal.h> then signal is redefined as __bsd_signal and signal has
the BSD semantics.  Both versions of signal are library routines built
on top of sigaction(2)."

I changed your example program to restore the signal handler routine
once the signal is raised and it worked as you described. I did not
try using <bsd/signal.h>. You may wish to try that. I prefer just
restoring the signal handler, since this avoid #ifdefs for different
platorms.

----ranga <ranga@soda.berkeley.edu>

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SIGALRM can't be delivered after longjmp from handler?

[Peter M. Jansson]

I'm sorry to be dense, but could you send me your modified version of my
test program?

In an earlier run, I was calling signal inside the signal handler before
the longjmp, and it had no effect, so I removed the code to make the
example as simple as possible.  It's possible I did it wrong, but if you
could send me your changes, I'd be grateful.

Thanks,
    Pete.

On Wed, 15 Mar 2000, Sriranga Veeraraghavan wrote:

>
> For other signals like SEGV and BUS and INTR, I had to re-enable the
> signal by calling signal() after longjmp as specified in the signal(2)
> manpage for Linux:
>
> "Unlike on BSD systems, signals under Linux are reset to their default
> behavior when raised.  However, if you include <bsd/signal.h> instead
> of <signal.h> then signal is redefined as __bsd_signal and signal has
> the BSD semantics.  Both versions of signal are library routines built
> on top of sigaction(2)."
>
> I changed your example program to restore the signal handler routine
> once the signal is raised and it worked as you described. I did not
> try using <bsd/signal.h>. You may wish to try that. I prefer just
> restoring the signal handler, since this avoid #ifdefs for different
> platorms.
>
> ----ranga <ranga@soda.berkeley.edu>
>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SIGALRM can't be delivered after longjmp from handler?

[David A. Gatwood]

On Wed, 15 Mar 2000, Peter M. Jansson wrote:

>
> I wrote the example that follows to illustrate what I think is a
> problem with signal delivery.  If this program works, then it should run
> in 5 cycles; the first 2 end with the "Timed out" message, while the
> last 3 end with the "Wait interrupted" message.  On my PowerMac 7200
> running 2.2.15pre3, I get 2 "Timed out" cycles, one "Wait interrupted"
> cycle, and then two more "Timed out" cycles.  What I think is going on
> is that, once the SIGALRM handler executes the longjmp, no further
> SIGALRM signals are delivered to the process -- I don't know if this is
> because the signals aren't delivered, or because the setitimer call
> isn't working.  I've observed this example to run correctly on BSD/OS,
> IRIX, and Solaris, and seen it fail on LinuxPPC and Linux x86.

Some OSes automatically reset signal handlers to SIG_DFL (which is SIG_IGN
for alarm) after they receive a signal and some leave the signal hndler in
place.  The BSDs to the latter, and Linux, IIRC, does the former.  You can
fix this by re-installing the handler during the signal handler function,
but the better way is to use sigaction instead of signal, which will give
consistent behaviour on all platforms.


Later,
David


> -------------------------------
>
> #include <signal.h>
> #include <setjmp.h>
> #include <sys/time.h>
> #include <stdio.h>
>
> static jmp_buf env;
> static unsigned int count = 0;
>
> static void
> interrupt()
> {

	signal(SIGALRM, interrupt);

>         printf ("Interrupt: %d\n", count);
>         if (count > 2)
>                 longjmp(env, 1);
> }
>
> main ()
> {
>         struct timeval tv;
>         struct itimerval it, oit;
>
>         while (count++ < 5) {
>                 printf("Cycle %d\n", count);
>
>                 if (setjmp(env)) {
>                         printf ("Wait interrupted\n");
>                 } else {
>                         if (signal(SIGALRM, interrupt) == SIG_ERR)
>                                 perror("signal");
>                         getitimer(ITIMER_REAL, &oit);
>                         timerclear(&it.it_interval);
>                         it.it_value.tv_sec = 2;
>                         it.it_value.tv_usec = 16665;
>                         if (setitimer(ITIMER_REAL, &it, &oit) < 0)
>                         perror("tick");
>                         printf ("Set timer; waiting...\n");
>                         tv.tv_sec = 5;
>                         tv.tv_usec = 0;
>                         select(0, NULL, NULL, NULL, &tv);
>                         printf ("Timed out\n");
>                 }
>         }
> }


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SIGALRM can't be delivered after longjmp from handler?

[Peter M. Jansson]

I made this exact change, and the program's behavior is unchanged.  Did
you compile and run the program with your change and observe different
behavior?  I still get only one "Wait interrupted" instead of three.

The signal is being delivered multiple times, it just isn't delivered
anymore after the longjmp, so I'm not sure that resetting the signal
handler is involved in this problem.

Pete.

On Wed, 15 Mar 2000, David A. Gatwood wrote:

> > static void
> > interrupt()
> > {
>
> 	signal(SIGALRM, interrupt);
>
> >         printf ("Interrupt: %d\n", count);
> >         if (count > 2)


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SIGALRM can't be delivered after longjmp from handler?

[David A. Gatwood]

On Wed, 15 Mar 2000, Peter M. Jansson wrote:

> I made this exact change, and the program's behavior is unchanged.  Did
> you compile and run the program with your change and observe different
> behavior?  I still get only one "Wait interrupted" instead of three.
>
> The signal is being delivered multiple times, it just isn't delivered
> anymore after the longjmp, so I'm not sure that resetting the signal
> handler is involved in this problem.

*ponders*....  Try sigsetjmp and siglongjmp


David


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SIGALRM can't be delivered after longjmp from handler?

[Peter M. Jansson]

Did that; no effect.

Pete.

On Wed, 15 Mar 2000, David A. Gatwood wrote:

> *ponders*....  Try sigsetjmp and siglongjmp


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SIGALRM can't be delivered after longjmp from handler?

[David A. Gatwood]

On Wed, 15 Mar 2000, Peter M. Jansson wrote:

> Did that; no effect.

Well, it did for me, but I had to change the location of the signal()
line.  The installation of the signal handler has to occur before the
sigsetjmp or else the longjmp() restores an empty set of handlers.


1.  Move the if (signal(...)) line to right after the printf("Cycle...")
line

2.  Change setjmp(jmp_buf) to sigsetjmp(jmp_buf,1)

3.  Change longjmp to siglongjmp

4.  add a signal(...) line to the beginning of the signal handler

The program then works as it did on *BSD.


David


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SIGALRM can't be delivered after longjmp from handler?

[Peter M. Jansson]

OK...I just tried this with setting the second parameter of sigsetjmp to
1, instead of leaving it at 0.  I need to RTFM more to understand why it
made a difference, but at least it works.

Thanks all!

Pete.

On Wed, 15 Mar 2000, David A. Gatwood wrote:

> *ponders*....  Try sigsetjmp and siglongjmp


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SIGALRM can't be delivered after longjmp from handler?

[D.J. Barrow]

I reported this bug & other signal handling ones on
the mailing list over a year ago, I ported the signal
code to S/390 & found that tftp wasn't working & even
sent demo code of this problem to the mailing list
needless to say I was more or less ignored. There also
is a problem in the bloody moronic way the power pc's
signal handler queues multiple signals in the user
spaces stack in do_signal & when a longjmp is done out
of the signal handler all the queued signals are
trashed & dropped ( so much for reliable signal
handling ) & the old blocked states are also lost.

A partial cure for the blocked signals as you
correctly stated is to use siglongjmp & sigsetjmp
which will unblock the SIGALRM however this doesn't
get rid of the problem that if multiple signals are
put on the stack for delivery at the same time they
are lost if a siglongjmp is done out of the first one
to be delivered. The intel code should be copied is
still not great but a good deal better than the PPC
crap & only attempts to deliver one signal at a time &
thus circumventing this problem.


After quickly looking at the 2.3.48 source I believe
this problem is still there.
--- "David A. Gatwood"
<dgatwood@deepspace.mklinux.org> wrote:
>
> On Wed, 15 Mar 2000, Peter M. Jansson wrote:
>
> > Did that; no effect.
>
> Well, it did for me, but I had to change the
> location of the signal()
> line.  The installation of the signal handler has to
> occur before the
> sigsetjmp or else the longjmp() restores an empty
> set of handlers.
>
>
> 1.  Move the if (signal(...)) line to right after
> the printf("Cycle...")
> line
>
> 2.  Change setjmp(jmp_buf) to sigsetjmp(jmp_buf,1)
>
> 3.  Change longjmp to siglongjmp
>
> 4.  add a signal(...) line to the beginning of the
> signal handler
>
> The program then works as it did on *BSD.
>
>
> David
>
>
>
>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/