This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread
- From: "redi at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 09 Jan 2013 14:42:00 +0000
- Subject: [Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread
- Auto-submitted: auto-generated
- References: <bug-55917-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> 2013-01-09 14:42:00 UTC ---
(In reply to comment #5)
> Yes, I thought two reports were in order, as they are only vaguely related. To
> me, this one is the most important problem. I struggle to understand how I can
> be the first to have this problem. Surely it must be an enormous problem if
> you use std::thread? I'm working on a somewhat large multi-threaded program,
> and if there's an exception anywhere, e.g. a failed range-check in a container,
> it's *completely impossible* to find the problem in a debugger.
If you're running in the debugger, rather than examining a core file
post-mortem, you can use "catch throw" or "break __cxa_throw" to break when the
exception is thrown.
Otherwise you already know the workaround, put 'noexcept' on the function you
pass to std::thread (which breaks pthread_cancel but if you're not using that
it doesn't matter.)
> We've now
> switched to boost::thread instead because it does not have this problem.
>
> I must say that I'm very surprised that you call it an enhancement,
The current implementation conforms to the standard.
> and that
> you consider closing it as WONTFIX,
I've explained why it can't easily be changed, unless anyone has some idea I
haven't thought of yet to preserve pthread_cancel behaviour and preserve the
requirement that std::terminate() is called.
> seeing how the current behavior is so
> mindbogglingly unfriendly. There is a reason why GCC does not unwind the stack
> for non-threaded unhandled exceptions.
The behaviour comes directly from the explicit requirement in the standard that
an unhandled exception in a std::thread must call std::terminate.
If it's guaranteed that an uncaught exception leaving that function will still
call terminate, then the catch(...) block could be removed. Maybe I could do
that conditionally for targets where it's known to work as required.