[Bug libstdc++/59392] New: crash on throw from "unexpected exception" handler with ARM EABI unwinder

[roland at gnu dot org]

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.