Re: Hang in throw
On Sep 22, 10:42 pm, Marcel M=FCller <news.5.ma...@spamgourmet.com>
wrote:
James Kanze wrote:
[...]
However, there are places, where this is unwise, because you
are currently executing a callback from the runtime, e.g. a
signal handler.
Throwing an exception from a signal handler isn't allowed,
and may not work. Or it may work most of the time, but not
always. (It's undefined behavior.)
That's what I mean. So you have to be very careful since many
runtime functions may throw unhandled exceptions.
Exceptions aren't the only problems in this regard. There's
really very, very little that you can do from a signal handler.
(I don't know about Windows, but under Unix, you can block a
thread on them, and handle them there. Which is definitely to
be preferred if you need to handle signals.)
- You may have corrupted the free space arena previously,
which causes the code to hang when constructing the string
for the exception. In fact, any previous undefined
behavior can lead to this sort of problem. But corrupting
the free space arena seems most common.
I had almost no heap corruption in the last years. Since I
consequently switched to C++ strings, smart pointers and smart
array pointers or STL containers, the problem has gone. In
case of the smart array pointers I use only implementations
that keep track of the size.
Agreed. If you're using C++ correctly, heap corruption should
be very rare---you never dynamically allocate C style arrays
yourself, only single objects, and the syntax of the new
operator more or less ensures that you'll get the right amount
of memory for it. Never the less, historically, it has been a
serious problem, and judging from the postings here, there are
still a lot of people using C style arrays, sprintf and who
knows what other older techniques.
--
James Kanze