[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread

2017-06-12 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread

2017-06-12 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 --- Comment #16 from Jonathan Wakely --- Author: redi Date: Mon Jun 12 16:37:28 2017 New Revision: 249130 URL: https://gcc.gnu.org/viewcvs?rev=249130=gcc=rev Log: PR libstdc++/55917 do not handle exceptions in std::thread PR

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread

2016-06-20 Thread howard.hinnant at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 --- Comment #15 from Howard Hinnant --- To help clarify my proposal, here is a patch: diff --git a/libstdc++-v3/src/c++11/thread.cc b/libstdc++-v3/src/c++11/thread.cc index 906cafa..cfca178 100644 --- a/libstdc++-v3/src/c++11/thread.cc +++

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread

2016-05-20 Thread howard.hinnant at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 Howard Hinnant changed: What|Removed |Added CC||howard.hinnant at gmail dot com ---

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread

2014-11-24 Thread rogero at howzatt dot demon.co.uk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 Roger Orr rogero at howzatt dot demon.co.uk changed: What|Removed |Added CC||rogero at

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread

2013-07-02 Thread yuri.aksenov at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 Yuri Aksenov yuri.aksenov at gmail dot com changed: What|Removed |Added CC||yuri.aksenov

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread

2013-07-02 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Yuri Aksenov from comment #7) If it's guaranteed that an uncaught exception leaving that function will still call terminate, then the catch(...) block could be

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread

2013-07-02 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org --- P.S. I do want to improve the behaviour, and I think we can make a change for targets where we know the behaviour is OK, but we need to check carefully that it works correctly, not

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread

2013-07-02 Thread yuri.aksenov at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 --- Comment #10 from Yuri Aksenov yuri.aksenov at gmail dot com --- OK, [thread.thread.constr]/4 says: If the invocation of INVOKE(decay_copy( std::forwardF(f)), decay_copy(std::forwardArgs(args))...) terminates with an uncaught exception,

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread

2013-07-02 Thread yuri.aksenov at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 --- Comment #11 from Yuri Aksenov yuri.aksenov at gmail dot com --- Where is that guaranteed? Where is it implemented? And here is stack trace of patched version, it seems to be implemented in __cxxabiv1::__cxa_throw (gdb) bt #0

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread

2013-07-02 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org --- Yes it will probably work on all platforms using the Itanium exception-handling ABI, unless the OS's pthread_create (or equiv) has explicit exception-handling.

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread

2013-01-09 Thread tobias at ringis dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 --- Comment #1 from Tobias Ringström tobias at ringis dot se 2013-01-09 13:22:52 UTC --- Created attachment 29120 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29120 Test program to illustrate the problem

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread

2013-01-09 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Severity|normal

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread

2013-01-09 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-09 13:48:04 UTC --- Ah, I se PR 55918 - thanks!

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread

2013-01-09 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-09 13:59:58 UTC --- One option would be to make the start function have a dynamic-exception-specification of throw(__cxxabiv1::__forced_unwind), which would allow the

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread

2013-01-09 Thread tobias at ringis dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 --- Comment #5 from Tobias Ringström tobias at ringis dot se 2013-01-09 14:06:08 UTC --- 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

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread

2013-01-09 Thread redi at gcc dot gnu.org
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