RE: Signal handler and longjmp question

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx
> To: yi.w@xxxxxxxx
> Subject: Re: Signal handler and longjmp question
> CC: linux-c-programming@xxxxxxxxxxxxxxx
>
> 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@xxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Assembler]     [Git]     [Kernel List]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [C Programming]     [Yosemite Campsites]     [Yosemite News]     [GCC Help]

  Powered by Linux