http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59392
Bug ID: 59392
Summary: crash on throw from "unexpected exception" handler
with ARM EABI unwinder
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
Target: arm-linux-gnueabihf
Created attachment 31382
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31382&action=edit
test case
I've observed this on trunk and on 4.6.3, but I think the bug has been there
since the introduction of ARM EABI unwinding in 4.2.
The attached test case crashes with a null pointer dereference (producing no
output) on ARM/EABI targets. On other targets (I only tested
x86_64-linux-gnu), it correctly crashes via abort after emitting a message
(i.e. std::terminate runs). The original case was more complex and used
std::set_terminate to set a handler that used longjmp, avoiding the abort. For
the test suite, it's probably most convenient to do that (or just exit with an
expected code in the terminate handler) rather than to detect that the default
std::terminate crash happened correctly vs a different crash.
The bug comes about in an obvious and straightforward way. But I don't know
the libsupc++ internals well enough to suggest an appropriate fix off hand.
What happens is that libstdc++-v3/libsupc++/eh_call.cc:__cxa_call_unexpected
does:
if (catch_type->__do_catch(&bad_exc, 0, 1))
i.e., passes a null pointer as the second argument to the __do_catch method.
libstdc++-v3/libsupc++/class_type_info.cc:__do_catch passes this argument on as
the second argument to __do_upcast.
In libstdc++-v3/libsupc++/class_type_info.cc:__do_upcast there is:
__do_upcast (dst_type, *obj_ptr, result);
i.e., unconditionally dereferencing OBJ_PTR (the second argument).
I'd like to see this get fixed on the trunk and 4.8 at least.
I'd be glad to pursue the fix myself if I had any idea what it should be.
