Throwing exceptions in a unix signal handler. Good idea?

Discussion in 'C++' started by thagor2008@googlemail.com, Jun 9, 2008.

  1. Guest

    Is the behaviour of throwing exceptions in a unix signal handler
    defined?

    eg:

    void sighandler(int sig)
    {
    ... do something
    throw myobj;
    }

    Under gcc on linux it seems to work as I'd expect - ie the exception
    handler wrapping the code running when the signal was caught catches
    the exception, but no one I've asked seems sure if this is how it
    should work or its just the gcc way of doing it.

    Can anyone shed any light on this?

    Thanks

    B2003
     
    , Jun 9, 2008
    #1
    1. Advertising

  2. writes:

    > Is the behaviour of throwing exceptions in a unix signal handler
    > defined?
    >
    > eg:
    >
    > void sighandler(int sig)
    > {
    > ... do something
    > throw myobj;
    > }
    >
    > Under gcc on linux it seems to work as I'd expect - ie the exception
    > handler wrapping the code running when the signal was caught catches
    > the exception, but no one I've asked seems sure if this is how it
    > should work or its just the gcc way of doing it.
    >
    > Can anyone shed any light on this?


    It's not a good idea.

    First, if it works with your compiler on your kernel, it may very well
    (and most probably) not work with another compiler or on another
    kernel.

    And even with your compiler on your kernel, if you add multithreads,
    there's no guarantee in which thread the signals are processed.

    Also, some syscalls may be interrupted by signals, with some exit code
    indicating it, to let the program retry the syscall. If you throw an
    exception from the signal handler, you may leave an unstable state.
    It means that this exception can be thrown from any place, not only to
    the very localized places where you call a function that throws it.

    So I would definitely not do that.
    --
    __Pascal Bourguignon__
     
    Pascal J. Bourguignon, Jun 9, 2008
    #2
    1. Advertising

  3. Guest

    On Jun 9, 4:26 pm, Pete Becker <> wrote:
    > From the C99 standard: "If the signal occurs other than as the result


    That C, not C++.

    > So, unless the signal came from a call to abort or raise, the behavior
    > is undefined.


    It may be undefined from the point of view of the C standard , but not
    from the unix standard otherwise there'd be no point using signals -
    every time a handler was called you'd have to hold your breath and
    hope the program didn't crash!

    I'm only interested in the specific combination of C++ exceptions and
    signal handlers since once stores the stack and one forces an unwind.
    Are compilers smart enough to know to pop the signal handler stack
    first and return to where the signal occured before unwinding the
    stack for the exception is the question.

    B2003
     
    , Jun 9, 2008
    #3
  4. Noah Roberts Guest

    wrote:
    > On Jun 9, 4:26 pm, Pete Becker <> wrote:
    >> From the C99 standard: "If the signal occurs other than as the result

    >
    > That C, not C++.
    >
    >> So, unless the signal came from a call to abort or raise, the behavior
    >> is undefined.

    >
    > It may be undefined from the point of view of the C standard , but not
    > from the unix standard otherwise there'd be no point using signals -
    > every time a handler was called you'd have to hold your breath and
    > hope the program didn't crash!


    You still need to ask in the OS/compiler specific newsgroup that can
    tell you the mechanics of that system. C++ says nothing about it and it
    works differently on the different systems.
     
    Noah Roberts, Jun 9, 2008
    #4
  5. Ian Collins Guest

    wrote:
    > On Jun 9, 4:26 pm, Pete Becker <> wrote:
    >> From the C99 standard: "If the signal occurs other than as the result

    >
    > That C, not C++.
    >
    >> So, unless the signal came from a call to abort or raise, the behavior
    >> is undefined.

    >
    > It may be undefined from the point of view of the C standard , but not
    > from the unix standard otherwise there'd be no point using signals -
    > every time a handler was called you'd have to hold your breath and
    > hope the program didn't crash!
    >

    It is also undefined in the C++ standard, which refers to the C standard.

    > I'm only interested in the specific combination of C++ exceptions and
    > signal handlers since once stores the stack and one forces an unwind.
    > Are compilers smart enough to know to pop the signal handler stack
    > first and return to where the signal occured before unwinding the
    > stack for the exception is the question.
    >

    Only a platform specific group could answer that. There isn't a
    portable standard C++ answer (other than "it's undefined").


    --
    Ian Collins.
     
    Ian Collins, Jun 9, 2008
    #5
  6. red floyd Guest

    On Jun 9, 12:47 pm, Ian Collins <> wrote:
    > wrote:
    > > On Jun 9, 4:26 pm, Pete Becker <> wrote:
    > >> From the C99 standard: "If the signal occurs other than as the result

    >
    > > That C, not C++.

    >
    > >> So, unless the signal came from a call to abort or raise, the behavior
    > >> is undefined.

    >
    > > It may be undefined from the point of view of the C standard , but not
    > > from the unix standard otherwise there'd be no point using signals -
    > > every time a handler was called you'd have to hold your breath and
    > > hope the program didn't crash!

    >
    > It is also undefined in the C++ standard, which refers to the C standard.
    >
    > > I'm only interested in the specific combination of C++ exceptions and
    > > signal handlers since once stores the stack and one forces an unwind.
    > > Are compilers smart enough to know to pop the signal handler stack
    > > first and return to where the signal occured before unwinding the
    > > stack for the exception is the question.

    >
    > Only a platform specific group could answer that. There isn't a
    > portable standard C++ answer (other than "it's undefined").


    Ian is right. The Linux g++ docs flat out say it's undefined.
     
    red floyd, Jun 9, 2008
    #6
  7. James Kanze Guest

    On Jun 9, 5:45 pm, wrote:
    > On Jun 9, 4:26 pm, Pete Becker <> wrote:


    > > From the C99 standard: "If the signal occurs other than as
    > > the result


    > That C, not C++.


    Included in the C++ standard by reference.

    > > So, unless the signal came from a call to abort or raise,
    > > the behavior is undefined.


    > It may be undefined from the point of view of the C standard ,
    > but not from the unix standard otherwise there'd be no point
    > using signals - every time a handler was called you'd have to
    > hold your breath and hope the program didn't crash!


    Not if you only do things which are allowed in the signal
    handler. Posix allows you to call a certain number of system or
    library functions, in addition to what the C standard allows,
    but it's still very limited. (Of course, if you're only under
    Posix, you won't be using signal() anyway.)

    > I'm only interested in the specific combination of C++
    > exceptions and signal handlers since once stores the stack and
    > one forces an unwind. Are compilers smart enough to know to
    > pop the signal handler stack first and return to where the
    > signal occured before unwinding the stack for the exception is
    > the question.


    The problem is that signals can arrive asynchronously. At a
    moment, for example, when the stack frame isn't set up
    correctly, and stack walkback isn't possible. In practice, it
    is very, very difficult to implement it so that it can work
    reliably, and I know of no system which does so.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Jun 10, 2008
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. C

    Throwing Exceptions

    C, Nov 6, 2003, in forum: ASP .Net
    Replies:
    2
    Views:
    374
    Kevin Spencer
    Nov 6, 2003
  2. Joseph Millar
    Replies:
    5
    Views:
    1,752
    Marc Rochkind
    Jul 10, 2003
  3. Marc Rochkind
    Replies:
    0
    Views:
    430
    Marc Rochkind
    Jul 9, 2003
  4. Michael Pronath
    Replies:
    1
    Views:
    1,174
    Diez B. Roggisch
    Jan 3, 2005
  5. Replies:
    10
    Views:
    1,243
    Big K
    Feb 2, 2005
Loading...

Share This Page