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.
