https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85471
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> --- Have you read https://gcc.gnu.org/bugs/ yet? (In reply to Andreas Otto from comment #2) > this is not as easy because this is a non trivial SW… what I mean… to just > use my test-case you have to setup a whole environment… the basic of a SW is > a client/server application using a non trivial protocol… We don't want the whole thing, we want a simple example that demonstrates the bug you are reporting. Otherwise your report is just hearsay. For example, here is a simple testcase which works perfectly and doesn't abort: #include <pthread.h> #include <thread> void f() { pthread_exit(nullptr); } int main() { std::thread t(f); t.join(); } Here is a testcase which calls std::terminate because the pthread_exit happens below a noexcept function: #include <pthread.h> #include <thread> void f() noexcept { pthread_exit(nullptr); } int main() { std::thread t(f); t.join(); } But this has a different stack trace to your valgrind output: ==25626== Memcheck, a memory error detector ==25626== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==25626== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==25626== Command: ./a.out ==25626== terminate called without an active exception ==25626== ==25626== Process terminating with default action of signal 6 (SIGABRT): dumping core ==25626== at 0x59459FB: raise (raise.c:51) ==25626== by 0x59477FF: abort (abort.c:89) ==25626== by 0x4ECC024: __gnu_cxx::__verbose_terminate_handler() (vterminate.cc:95) ==25626== by 0x4EC9C15: __cxxabiv1::__terminate(void (*)()) (eh_terminate.cc:47) ==25626== by 0x4EC9C60: std::terminate() (eh_terminate.cc:57) ==25626== by 0x4EC97AF: __gxx_personality_v0 (eh_personality.cc:670) ==25626== by 0x54E8FB4: _Unwind_ForcedUnwind_Phase2 (unwind.inc:175) ==25626== by 0x54E9574: _Unwind_ForcedUnwind (unwind.inc:207) ==25626== by 0x5700F0F: __pthread_unwind (unwind.c:121) ==25626== by 0x56F8754: __do_cancel (pthreadP.h:297) ==25626== by 0x56F8754: pthread_exit (pthread_exit.c:28) ==25626== by 0x400A4A: f() (th.cc:6) ==25626== by 0x4EF617E: execute_native_thread_routine (thread.cc:83) ==25626== ==25626== Process terminating with default action of signal 11 (SIGSEGV) ==25626== General Protection Fault ==25626== at 0x5A63E9C: _dl_catch_error (dl-error-skeleton.c:187) ==25626== by 0x5A63616: dlerror_run (dl-libc.c:46) ==25626== by 0x5A63616: __libc_dlclose (dl-libc.c:222) ==25626== by 0x5703C18: nptl_freeres (in /usr/lib64/libpthread-2.25.so) ==25626== by 0x5A8EF11: __libc_freeres (in /usr/lib64/libc-2.25.so) ==25626== by 0x4A286DB: _vgnU_freeres (vg_preloaded.c:77) ==25626== ==25626== HEAP SUMMARY: ==25626== in use at exit: 360 bytes in 3 blocks ==25626== total heap usage: 4 allocs, 1 frees, 73,064 bytes allocated ==25626== ==25626== LEAK SUMMARY: ==25626== definitely lost: 0 bytes in 0 blocks ==25626== indirectly lost: 0 bytes in 0 blocks ==25626== possibly lost: 288 bytes in 1 blocks ==25626== still reachable: 72 bytes in 2 blocks ==25626== suppressed: 0 bytes in 0 blocks ==25626== Rerun with --leak-check=full to see details of leaked memory ==25626== ==25626== For counts of detected and suppressed errors, rerun with: -v ==25626== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Segmentation fault (core dumped) So we need a testcase showing the problem.
