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

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

[tobias at ringis dot se]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917

             Bug #: 55917
           Summary: Impossible to find/debug unhandled exceptions in an
                    std::thread
    Classification: Unclassified
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: tobias@ringis.se


If an unhandled exception occurs in an std::thread, the stack is unwound before
std::terminate is called, which makes it impossible to find the location of the
exception.

I emailed gcc-help about this about a year ago, and learned that a fix was
supposed to be applied for 4.7, but that fix didn't work out. Here's my post:

  http://gcc.gnu.org/ml/gcc-help/2011-11/msg00140.html

The reason for the unwound stack is that libstdc++'s function that calls the
user's thread function contains a try/catch all statement.  The supposed fix
was to use noexcept on the internal thread main function, and the reason why it
did not work out is described here:

  http://gcc.gnu.org/ml/gcc-help/2013-01/msg00068.html

I've tested 4.6, 4.7 and a 4.8 snapshot with identical results.  See the
attached test program tmp4.cpp. Compile with:

  g++ -std=c++0x -g tmp4.cpp -lpthread

Run in gdb:

~> gdb a.out
[...]
(gdb) r
Starting program: /home/tobias/a.out 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff7fd0700 (LWP 10278)]
terminate called after throwing an instance of 'std::runtime_error'
  what():  foo

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff7fd0700 (LWP 10278)]
0x000000318f036285 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install
glibc-2.14.90-24.fc16.9.x86_64 libgcc-4.6.3-2.fc16.x86_64
libstdc++-4.6.3-2.fc16.x86_64
(gdb) bt
#0  0x000000318f036285 in raise () from /lib64/libc.so.6
#1  0x000000318f037b9b in abort () from /lib64/libc.so.6
#2  0x00000031964bbc5d in __gnu_cxx::__verbose_terminate_handler() ()
   from /usr/lib64/libstdc++.so.6
#3  0x00000031964b9e16 in ?? () from /usr/lib64/libstdc++.so.6
#4  0x00000031964b9e43 in std::terminate() () from /usr/lib64/libstdc++.so.6
#5  0x0000003196470b0b in ?? () from /usr/lib64/libstdc++.so.6
#6  0x000000318fc07d90 in start_thread () from /lib64/libpthread.so.0
#7  0x000000318f0f119d in clone () from /lib64/libc.so.6
(gdb) 

As you can see, neither the thread's main function, nor foo() is in the
backtrace.

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::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

[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                      |enhancement

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> 2013-01-09 13:44:35 UTC ---
As I said at http://gcc.gnu.org/ml/gcc-help/2013-01/msg00068.html this can't be
changed for std::thread, see
http://gcc.gnu.org/ml/libstdc++/2012-12/msg00062.html and the patch at
http://gcc.gnu.org/ml/libstdc++/2012-12/msg00068.html for discussion and code
that absolutely requires exceptions of type __forced_unwind to be able to
escape the thread start function, otherwise thread cancellation crashes the
program, which is not acceptable.

If the function is not noexcept then it must catch exceptions to ensure
std::terminate is called as required, and catching the exception causes the
stack to be unwound. So it's difficult do anything about std::thread.

Please open a separate bug (with Component=c++) for the
http://gcc.gnu.org/ml/gcc-help/2013-01/msg00058.html issue when noexcept
interacts with a destructor on the stack.  That applies to code not using
std::thread too.

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::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

[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 cancellation exception to propagate (as required) but prevent
any other exceptions, but that would result in a call to std::unexpected()
rather than std::terminate(), and a user could have replaced the
unexpected_handler, so we would not be able to meet the requirement that
std::terminate() is called. On top of that, I think the stack would still get
unwound before the call to std:unexpected, and dynamic-exception-specifications
and unexpected handlers are deprecated in C++11.  So I don't think we want to
do that.

My inclination is to close this as WONTFIX.

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::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 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.  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, and that
you consider closing it as WONTFIX, 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.

Perhaps std::thread is not widely used yet, or I'm the only one with buggy
code?

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::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 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.

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::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 at gmail dot com

--- Comment #7 from Yuri Aksenov <yuri.aksenov at gmail dot com> ---
> 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.

I vote for this enhancement to remove catch(...) block from
execute_native_thread_routine function.

According to standard (15.3) Handling an exception
> If no matching handler is found, the function std::terminate() is called; 
> whether or not the stack is unwound before this call to std::terminate() is 
> implementation-defined (15.5.1).

So if we remove catch(...), std::terminate should be called anyway (it's a bug
otherwise). But GCC implementaion will leave stack unwound making it easier to
debug.
>From gcc-bugs-return-425564-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jul 02 10:36:06 2013
Return-Path: <gcc-bugs-return-425564-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8710 invoked by alias); 2 Jul 2013 10:36:06 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 8681 invoked by uid 48); 2 Jul 2013 10:36:03 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57746] rejected valid specialization of member function of class template (I think)
Date: Tue, 02 Jul 2013 10:36:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.7.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57746-4-8xx1bhYnTE@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57746-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57746-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-07/txt/msg00071.txt.bz2
Content-length: 1724

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW746

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Andy Lutomirski from comment #4)
> Daniel, I'm unconvinced that your interpretation is the intended one.

The definition is also a declaration, see [basic.def] p2, as Daniel pointed
out.

> [temp.explicit].4 says "A declaration of [list including member function]
> ... A definition of [list not including member function]".  If definitions
> were intended to be declarations in this context, then the second part would
> be redundant, I think.

That doesn't follow at all. The second part describes different types of
entities that have different requirements.

For the first list an explicit instantiation must follow a declaration (and a
definition also counts as a declaration) but for the second list an explicit
instantiation must follow a definition, a declaration is not sufficient.


> Regardless, the interesting case is:
>
> template<typename T>
> struct X
> {
>   static int val;
>   static void func();
> };
>
> // optionally: extern template struct X<int>;
>
> void something()
> {
>   X<int>::func();
> }
>
> in one file and
>
> struct X
> {
>   static int val;
>   static void func();
> };
>
> template<> void X<int>::func() {}
>
> in another.  I don't think this is an odr violation, since there is only one
> definition of anything that could be confused with X<int>::func.  g++ will
> happily compile and link it (without the extern template bit) and it will
> work.  It is supposed to?  Could a conforming compiler mangle the
> specialized version of func differently?

Isn't this ill-formed, with no diagnostic required, by both [temp] p6 and
[temp.expl.spec] p6?

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::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 removed. Maybe I could do 
> > that conditionally for targets where it's known to work as required.
> 
> I vote for this enhancement to remove catch(...) block from
> execute_native_thread_routine function.

This isn't a democracy ;)

> According to standard (15.3) Handling an exception
> > If no matching handler is found, the function std::terminate() is called; 
> > whether or not the stack is unwound before this call to std::terminate() is 
> > implementation-defined (15.5.1).
> 
> So if we remove catch(...), std::terminate should be called anyway (it's a
> bug otherwise).

The catch(...) is there to provide the [thread.thread.constr]/4 requirement
that std::terminate is called. If it isn't there, are you saying Pthreads or
the OS guarantees that an exception in the function passed to pthread_create()
will cause a call to std::terminate()? Where is that guaranteed?  Where is it
implemented?

You can't just say "rely on the implementation, it's a bug otherwise", this
code **is** the implementation.
>From gcc-bugs-return-425568-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jul 02 11:22:59 2013
Return-Path: <gcc-bugs-return-425568-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10386 invoked by alias); 2 Jul 2013 11:22:59 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 10360 invoked by uid 48); 2 Jul 2013 11:22:54 -0000
From: "dirkjan at ochtman dot nl" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/57777] New: Python module fails compilation with "-march=core-avx2 -O3"
Date: Tue, 02 Jul 2013 11:22:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.7.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dirkjan at ochtman dot nl
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-57777-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-07/txt/msg00075.txt.bz2
Content-length: 2172

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW777

            Bug ID: 57777
           Summary: Python module fails compilation with "-march=core-avx2
                    -O3"
           Product: gcc
           Version: 4.7.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dirkjan at ochtman dot nl

gcc-4.7 "-march=core-avx2 -O3" -> fails
gcc-4.7 "-march=core-avx2 -O2" -> succeeds

gcc-4.7 "-march=core-avx-i -O3" -> succeeds
gcc-4.7 "-march=core-avx-i -O2" -> succeeds

gcc-4.6 "-march=core-avx-i -O3" -> succeeds
gcc-4.6 "-march=core-avx-i -O2" -> succeeds

Failure happens like this:

building '_random' extension
x86_64-pc-linux-gnu-gcc -pthread -fPIC -fno-strict-aliasing -march=core-avx2
-O2 -pipe -Wall -g -O3 -fwrapv -DNDEBUG -I. -IInclude
-I/var/tmp/portage/dev-lang/python-2.7.5/work/Python-2.7.5/Include
-I/var/tmp/portage/dev-lang/python-2.7.5/work/x86_64-pc-linux-gnu -c
/var/tmp/portage/dev-lang/python-2.7.5/work/Python-2.7.5/Modules/_randommodule.c
-o
build/temp.linux-x86_64-2.7/var/tmp/portage/dev-lang/python-2.7.5/work/Python-2.7.5/Modules/_randommodule.o
x86_64-pc-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,--as-needed
-Wl,--hash-style=gnu -L. -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -L.
-fno-strict-aliasing -march=core-avx2 -O2 -pipe -Wall -g -O3 -fwrapv -DNDEBUG
-I. -IInclude
-I/var/tmp/portage/dev-lang/python-2.7.5/work/Python-2.7.5/Include
build/temp.linux-x86_64-2.7/var/tmp/portage/dev-lang/python-2.7.5/work/Python-2.7.5/Modules/_randommodule.o
-L/usr/local/lib -L. -lpython2.7 -o build/lib.linux-x86_64-2.7/_random.so

/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld:
build/temp.linux-x86_64-2.7/var/tmp/portage/dev-lang/python-2.7.5/work/Python-2.7.5/Modules/_randommodule.o:
relocation R_X86_64_32S against `.rodata' can not be used when making a shared
object; recompile with -fPIC

build/temp.linux-x86_64-2.7/var/tmp/portage/dev-lang/python-2.7.5/work/Python-2.7.5/Modules/_randommodule.o:
could not read symbols: Bad value

collect2: error: ld returned 1 exit status

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::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 just remove the catch(...)

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::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::forward<F>(f)), 
> decay_copy(std::forward<Args>(args))...) terminates with an uncaught exception, 
> std::terminate shall be called.

And [except.handle]/9 says:
> If no matching handler is found, the function std::terminate() is called

So we don't need to set default handler unless there is bug in implementation
of [except.handle]/9

I have tested std::thread with removed catch(...) for both -m32 and -m64
environments on
gcc version 4.7.1 20120723 [gcc-4_7-branch revision 189773] (SUSE Linux) 
Target: x86_64-suse-linux

And I can test it on
Target: armv5b-softfloat-linux

But I can not be shure for any possible target

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::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  0x00007ffff703ad25 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff703c1a8 in __GI_abort () at abort.c:91
#2  0x00007ffff791d68d in __gnu_cxx::__verbose_terminate_handler () at
../../../../libstdc++-v3/libsupc++/vterminate.cc:95
#3  0x00007ffff791b796 in __cxxabiv1::__terminate (handler=<optimized out>) at
../../../../libstdc++-v3/libsupc++/eh_terminate.cc:40
#4  0x00007ffff791b7c3 in std::terminate () at
../../../../libstdc++-v3/libsupc++/eh_terminate.cc:50
#5  0x00007ffff791b9ee in __cxxabiv1::__cxa_throw (obj=0x7ffff0000940,
tinfo=<optimized out>, dest=<optimized out>) at
../../../../libstdc++-v3/libsupc++/eh_throw.cc:83
#6  0x00000000004010f2 in f () at main.cpp:5
#7  0x000000000040242d in std::_Bind_simple<void
(*())()>::_M_invoke<>(std::_Index_tuple<>) (this=0x606040) at
/usr/include/c++/4.7/functional:1598
#8  0x000000000040237d in std::_Bind_simple<void (*())()>::operator()()
(this=0x606040) at /usr/include/c++/4.7/functional:1586
#9  0x0000000000402316 in std::thread::_Impl<std::_Bind_simple<void (*())()>
>::_M_run() (this=0x606028) at /usr/include/c++/4.7/thread:115
#10 0x000000000040266d in std::(anonymous
namespace)::execute_native_thread_routine (__p=0x606028) at thread.cpp:73
#11 0x00007ffff7bc6e0e in start_thread (arg=0x7ffff7005700) at
pthread_create.c:305
#12 0x00007ffff70ea2cd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:115

[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::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

[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 howzatt dot demon.co.uk

--- Comment #13 from Roger Orr <rogero at howzatt dot demon.co.uk> ---
I am also affected by this problem.
What is the status of the idea Jonathan made (2013-07-02 11:26:53 UTC):

  ... and I think we can make a change for targets where we know the behaviour
is OK ...