I would like to have a handler for a program-generated signal
(like SEGV) throw an exception, so I can get the benefits of
stack unwinding.

Unfortunately, in Sun's Solaris implementation, correct
stack unwinding after delivery of a signal is, in general,
impossible.  Indeed, Eric Larson of Sun has stated that
"the best thing to do when you receive signals is to
close up all your files and quit with an error message".

This seems to go against the spirit of the use of try/catch
blocks to deal with recovery from exceptional situations.

Is this addressed by the language definition?  Should it be?
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article 2971@elmer.tcinc.com, "Wesley E. Munsil"
<wmunsil@elmer.tci.com> writes:
>I would like to have a handler for a program-generated signal
>(like SEGV) throw an exception, so I can get the benefits of
>stack unwinding.

Sorry, you can't (portably) do it. Signals are in general asynchronous,
and exceptions are by definition synchronous. An exception can only
be thrown at well-defined points in the program exection, and is always
from the current thread. Since you cannot make any of those guarantees
for signals, throwing an exception from a signal handler is unlikely
to work. In addition, the things you are allowed to do from a signal
handler according to the C adn C++ standards are extremely minimal --
you can't depend on being able to do much more than setting a global
volatile variable and returning.

>Unfortunately, in Sun's Solaris implementation, correct
>stack unwinding after delivery of a signal is, in general,
>impossible.  Indeed, Eric Larson of Sun has stated that
>"the best thing to do when you receive signals is to
>close up all your files and quit with an error message".

Unless of course you are willing to deal with the signal, or if you
can determine that it is uninteresting.

>This seems to go against the spirit of the use of try/catch
>blocks to deal with recovery from exceptional situations.

Signals and exception handling are different categories of things. The
"spirit" of try/catch has nothing to do with signals.

---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Wesley E. Munsil <wmunsil@elmer.tci.com> wrote:
: I would like to have a handler for a program-generated signal
: (like SEGV) throw an exception, so I can get the benefits of
: stack unwinding.

First of all, you can't catch SEGV. You program will be killed
by the kernel, and rigtfully so.

: Unfortunately, in Sun's Solaris implementation, correct
: stack unwinding after delivery of a signal is, in general,
: impossible.

That's correct. First of all, neither ANSI C nor POSIX guarantees that
you can call a function from a signal handler. Second of all,
even if you can do it in your particular implementation,
your code will not be portable. Third of all, many standard library
functions are not reentrant, so if you try to call them from
a signal handler you'll get in trouble. Your chances of
calling something that you shouldn't from an exception handler
is even greater.

And, most important of all, C++ exceptions are not meant for handling
asynchronous events, and no requirements exists that compiler
and standard libraries handle exceptions correctly, if thrown from
a signal handler. What you can do is to raise a flag in the signal
handler, which will cause an exception thrown in some other well-determined
place.

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

>>>>> Wesley E Munsil <wmunsil@elmer.tci.com> writes:

> I would like to have a handler for a program-generated signal
> (like SEGV) throw an exception, so I can get the benefits of
> stack unwinding.

> Unfortunately, in Sun's Solaris implementation, correct
> stack unwinding after delivery of a signal is, in general,
> impossible.

> This seems to go against the spirit of the use of try/catch
> blocks to deal with recovery from exceptional situations.

Perhaps, but C++ exceptions are synchronous events, while C signals (at
least some of them) are asynchronous.  The implementer can assume that an
exception can only be thrown from a function call; if C signals could be
converted to exceptions, this would not be true, and the implementation
would have to handle exceptions thrown, say, from the function prologue.

Jason
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Wesley E. Munsil wrote:
>
> I would like to have a handler for a program-generated signal
> (like SEGV) throw an exception, so I can get the benefits of
> stack unwinding.
>
> Unfortunately, in Sun's Solaris implementation, correct
> stack unwinding after delivery of a signal is, in general,
> impossible.  Indeed, Eric Larson of Sun has stated that
> "the best thing to do when you receive signals is to
> close up all your files and quit with an error message".
>
> This seems to go against the spirit of the use of try/catch
> blocks to deal with recovery from exceptional situations.

The only safe approach is to set a global variable and test that
variable at key points of your code which would then throw the
desired exception.


--
___________________________________________________________________
Marcelo Cantos, Research Assistant          marcelo@mds.rmit.edu.au
Multimedia Database Systems Group              Tel: +61-3-9282-2497
723 Swanston St, Carlton VIC 3053, Australia   Fax: +61-3-9282-2490
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

[Crossposted and followups redirected to comp.unix.programmer,
since this has drifted off-topic for comp.std.c++.]

Oleg Zabluda <zabluda@math.psu.edu> writes:

>Wesley E. Munsil <wmunsil@elmer.tci.com> wrote:
>: I would like to have a handler for a program-generated signal
>: (like SEGV) throw an exception, so I can get the benefits of
>: stack unwinding.
>
>First of all, you can't catch SEGV. You program will be killed
>by the kernel, and rigtfully so.

No, that's not correct.  All the Unix systems I've tried it on --
Linux, Solaris, Alpha/OSF, and IRIX -- allow you to catch SIGSEGV.
You can even use mprotect() to turn off write protection and then
continue.

Here's what Mike Stump from Cygnus had to say when this question
came up last time (look for the thread "turning unix signals
into G++ exceptions" with dejanews):

 | Throwing an exception from within a signal handler is not valid ANSI
 | C++, if you do so, you do so at your own risk.  I have tried to make
 | the compiler (g++) so that exceptions can be asynchronous (thrown from
 | inside signal handlers and everything just work), but some items
 | remain it you want it to work flawlessly all the time.  It should work
 | ok some/most of the time now.
 |
 | If you run the instruction stream up to the next call instruction
 | before throwing the exception you should be really safe.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]