public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/59392] New: crash on throw from "unexpected exception" handler with ARM EABI unwinder
@ 2013-12-05  0:10 roland at gnu dot org
  2013-12-05  0:35 ` [Bug libstdc++/59392] " mseaborn at chromium dot org
                   ` (5 more replies)
  0 siblings, 6 replies; 7+ messages in thread
From: roland at gnu dot org @ 2013-12-05  0:10 UTC (permalink / raw)
  To: gcc-bugs

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.


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2014-03-12 22:47 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-12-05  0:10 [Bug libstdc++/59392] New: crash on throw from "unexpected exception" handler with ARM EABI unwinder roland at gnu dot org
2013-12-05  0:35 ` [Bug libstdc++/59392] " mseaborn at chromium dot org
2013-12-09 17:32 ` roland at gnu dot org
2014-03-12 20:56 ` redi at gcc dot gnu.org
2014-03-12 22:42 ` roland at gcc dot gnu.org
2014-03-12 22:44 ` roland at gcc dot gnu.org
2014-03-12 22:47 ` roland at gnu dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).