Signal handler and longjmp question

Signal handler and longjmp question

[Yi Wang]

Hi, all
    I read from some book that a signal handler can either return or call exit, abort or longjmp, it is permitted by ANSI C.
    However, I remember that lonjmp never returns, which in turn causes the signal handler can not return. In that case, the kernel will think the program is in signal handler forever, am I right? 
    IMHO, I think that is too bad...

Leo

--------------------------------------
code sample:

jmp_buf buf;
static void signal_handler(int signo)
{
    longjmp(buf);
}
int main()
{
  signal(SIGUSR1, signal_handler);
  ...
  setjmp(buf);
  ...
  return 0;
}

Suppose the program received SIGUSR1 after setjmp has been called, is the program still in signal handle context after longjmp?


_________________________________________________________________
Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us

Re: Signal handler and longjmp question

[Steve Graegert]

On Dec 9, 2007 2:12 PM, Yi Wang <yi.w@live.com> wrote:
>
> Hi, all
>     I read from some book that a signal handler can either return or call exit, abort or longjmp, it is permitted by ANSI C.
>     However, I remember that lonjmp never returns, which in turn causes the signal handler can not return. In that case, the kernel will think the program is in signal handler forever, am I right?
>     IMHO, I think that is too bad...

This is not the case.  Rather than returning to the interrupted
statement, longjmp causes control to be sent back to the setjmp() in
the main program.  Since POSIX.1 does not specify whether setjmp and
longjmp save or restore the current set of blocked signals the use of
sigsetjmp/siglongjmp is recommended if signals must be handled.

longjmp does not return because setjmp first saves the environment to
which longjmp can return from another point in the program.  After
returning to setjmp the process does not know that it "has been
returned" from somewhere else.  So, technically longjmp cannot not
return.

A problem with the use of setjmp/longjmp is that the environment will
not be cleaned up (closing FDs, flushing buffers, freeing
heap-allocated memory, and the like).

	\Steve

--

Steve Grägert
DigitalEther.de
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Signal handler and longjmp question

[Yi Wang]

Well, I understand you.
Maybe I'm not expressing myself clearly.
The following drawing indicates how the kernel issues a signal. (ref:understanding linux kernel, 3rd, O'Reilly, Fig. 11-2)
Note that the function calls on the right column are kernel codes.
The kernel manages the frame setup and other stuff  the signal_handler()
I'm wondering if longjmp is called in signal_handler, the the handler won't return and the system_call(),sys_sigreturn()and restore_sigcontext() will never have chance to execute.
This will break kernel's routine of handling a signal.
And I think that's bad...


Program running ----->  do_signal()
   received signal               handle_signal()
                                         setup_frame()
                                       /
                                     /
                                   /
signal_handler()  <------/     
         |
       return
               \
                 \
                   \---->  system_call()
                                 sys_sigreturn()
                                       restore_sigcontext()
                                      /
                                    /
continue program  <- ----/




> Date: Sun, 9 Dec 2007 15:06:22 +0100
> From: graegerts@gmail.com
> To: yi.w@live.com
> Subject: Re: Signal handler and longjmp question
> CC: linux-c-programming@vger.kernel.org
>
> On Dec 9, 2007 2:12 PM, Yi Wang  wrote:
>>
>> Hi, all
>> I read from some book that a signal handler can either return or call exit, abort or longjmp, it is permitted by ANSI C.
>> However, I remember that lonjmp never returns, which in turn causes the signal handler can not return. In that case, the kernel will think the program is in signal handler forever, am I right?
>> IMHO, I think that is too bad...
>
> This is not the case. Rather than returning to the interrupted
> statement, longjmp causes control to be sent back to the setjmp() in
> the main program. Since POSIX.1 does not specify whether setjmp and
> longjmp save or restore the current set of blocked signals the use of
> sigsetjmp/siglongjmp is recommended if signals must be handled.
>
> longjmp does not return because setjmp first saves the environment to
> which longjmp can return from another point in the program. After
> returning to setjmp the process does not know that it "has been
> returned" from somewhere else. So, technically longjmp cannot not
> return.
>
> A problem with the use of setjmp/longjmp is that the environment will
> not be cleaned up (closing FDs, flushing buffers, freeing
> heap-allocated memory, and the like).
>
> \Steve
>
> --
>
> Steve Grägert
> DigitalEther.de
> -
> To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html

_________________________________________________________________
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html