[Bug c++/85471] closing a "thread" in "C++" using "pthread_exit(NULL)" creates a "SIGABRT"

2019-10-24 Thread amker at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85471

bin cheng  changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #6 from bin cheng  ---
I ran into a stackoverflow entry with following code:
#include 
#include 
#include 
#include 

static void cleanup(void *ptr)
{
}

void *child(void *ptr)
{
  pthread_cleanup_push(cleanup, NULL);
  pthread_exit(NULL);
  pthread_cleanup_pop(1);
  return NULL;
}

int main()
{
  pthread_t foo;
  pthread_create(, NULL, child, NULL);
  pthread_join(foo, NULL);
  return 0;
}

The abort can be reproduced when compiled using gcc-8.3 with following options:
$ g++ -o a.out test.cc -g -Wall -fexceptions  -pthread -static-libstdc++
-static-libgcc
$ gdb --args ./a.out
(gdb) r
(gdb) bt
#0  0xbf4972c8 in raise () from /lib64/libc.so.6
#1  0xbf498940 in abort () from /lib64/libc.so.6
#2  0x0040ec94 in _Unwind_SetGR ()
#3  0x00401c4c in __gxx_personality_v0 ()
#4  0xbec3fab8 in _Unwind_ForcedUnwind_Phase2
(exc=exc@entry=0xbf462670, context=context@entry=0xbf461560,
frames_p=frames_p@entry=0xbf461198)
at ../../../libgcc/unwind.inc:182
#5  0xbec3fea0 in _Unwind_ForcedUnwind (exc=0xbf462670,
stop=0xbf5f7950 , stop_argument=0xbf461a30) at
../../../libgcc/unwind.inc:217
#6  0xbf5fa15c in _Unwind_ForcedUnwind () from /lib64/libpthread.so.0
#7  0xbf5f7aac in __pthread_unwind () from /lib64/libpthread.so.0
#8  0xbf5f1a08 in pthread_exit () from /lib64/libpthread.so.0
#9  0x00401460 in child (ptr=0x0) at test.cc:13
#10 0xbf5f0bb0 in start_thread () from /lib64/libpthread.so.0
#11 0xbf53e4c0 in thread_start () from /lib64/libc.so.6

Issue with this case is because of static-libgcc, not sure if it's the same to
the original case.

Thanks

[Bug c++/85471] closing a "thread" in "C++" using "pthread_exit(NULL)" creates a "SIGABRT"

2018-12-20 Thread LpSolit at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85471

--- Comment #5 from Martin Liška  ---
(In reply to Andreas Otto from comment #4)
> change my C++ wrapper from "embedded data" (large amount of data) to just an
> embedded pointer (only 8byte pointer in the C++ class)
> 
> → the error is still there…
> 
> ==57730== Process terminating with default action of signal 6 (SIGABRT)
> ==57730==at 0x6BA2F67: raise (raise.c:55)
> ==57730==by 0x6BA4339: abort (abort.c:78)
> ==57730==by 0x4178DD: _Unwind_SetGR (unwind-dw2.c:273)
> ==57730==by 0x409B8C: __gxx_personality_v0 (eh_personality.cc:712)
> ==57730==by 0x72AC4A4: _Unwind_ForcedUnwind_Phase2 (unwind.inc:175)
> ==57730==by 0x72ACA64: _Unwind_ForcedUnwind (unwind.inc:207)
> ==57730==by 0x696098F: __pthread_unwind (unwind.c:126)
> ==57730==by 0x695A8B4: __do_cancel (pthreadP.h:283)
> ==57730==by 0x695A8B4: pthread_exit (pthread_exit.c:28)
> ==57730==by 0x506554E: libmsgque::SysExit(int, int) (sys.cc:1000)
> ==57730==by 0x5059987: libmsgque::MqSysExit(int, int) (msgque.h:2038)
> ==57730==by 0x505B4F8: libmsgque::MqExitP(libmsgque::MqS*, char const*,
> char const*) (msgque.cc:440)
> ==57730==by 0x50B2FAA: ccmsgque::MqC::ExitP(char const*, char const*)
> (MqC.cc:380)
> ==57730==by 0x405EF7: Filter6::EXIT() (Filter6.cc:80)
> ==57730==by 0x5099A15: ccmsgque::MqC::ProcCall(libmsgque::MqS*, void*)
> (ccmisc.cc:50)
> ==57730==by 0x5043DA3: libmsgque::MqCallbackCall(libmsgque::MqS*,
> libmsgque::MqCallbackS) (msgque_private.h:326)
> ==57730==by 0x5045368: libmsgque::pTokenInvoke(libmsgque::pTokenS
> const*) (token.cc:342)
> ==57730==by 0x507836C: libmsgque::pServiceStart(libmsgque::MqS*,
> libmsgque::MqErrorE (*)(void*, libmsgque::MqS**, libmsgque::MqEnvS*), void*)
> (service.cc:244)
> ==57730==by 0x502D33B: libmsgque::pEventStart(libmsgque::MqS*,
> libmsgque::MqEventS*, timeval const*) (event.cc:287)
> ==57730==by 0x5055AD3: libmsgque::pIoSelectStart(libmsgque::MqIoS*,
> timeval const*) (io.cc:267)
> ==57730==by 0x5078B3E: libmsgque::MqProcessEvent(libmsgque::MqS*, long,
> libmsgque::MqWaitOnEventE) (service.cc:377)
> ==57730==by 0x5063F70:
> libmsgque::MqSysServerThreadMain(libmsgque::MqSysServerThreadMainS*)
> (sys.cc:488)
> ==57730==by 0x5063FB7: libmsgque::sSysServerThreadInit(void*)
> (sys.cc:502)
> ==57730==by 0x6959723: start_thread (pthread_create.c:457)
> ==57730==by 0x6C5AE8C: clone (clone.S:109)
> ==57730== 
> ==57730== HEAP SUMMARY:
> ==57730== in use at exit: 160,370 bytes in 184 blocks
> ==57730==   total heap usage: 940 allocs, 756 frees, 677,695 bytes allocated
> ==57730== 
> ==57922== 
> ==57922== HEAP SUMMARY:
> ==57922== in use at exit: 72,944 bytes in 4 blocks
> ==57922==   total heap usage: 487 allocs, 483 frees, 273,097 bytes allocated
> ==57922== 
> ==57922== LEAK SUMMARY:
> ==57922==definitely lost: 0 bytes in 0 blocks
> ==57922==indirectly lost: 0 bytes in 0 blocks
> ==57922==  possibly lost: 0 bytes in 0 blocks
> ==57922==still reachable: 72,944 bytes in 4 blocks
> ==57922== suppressed: 0 bytes in 0 blocks
> ==57922== Rerun with --leak-check=full to see details of leaked memory
> ==57922== 
> ==57922== For counts of detected and suppressed errors, rerun with: -v
> ==57922== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
> ==57730== LEAK SUMMARY:
> 
> 
> but I have additional "leakcheck" data…
> 
> 
>  trans2-3-TE2-init-(3|binary|uds|cc.uds.thread) start
> ==67406== 672 bytes in 2 blocks are possibly lost in loss record 131 of 151
> ==67406==at 0x4C2C240: calloc (in
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==67406==by 0x40119E1: allocate_dtv (dl-tls.c:322)
> ==67406==by 0x401223D: _dl_allocate_tls (dl-tls.c:539)
> ==67406==by 0x695A180: allocate_stack (allocatestack.c:580)
> ==67406==by 0x695A180: pthread_create@@GLIBC_2.2.5 (pthread_create.c:654)
> ==67406==by 0x5064231: libmsgque::SysServerThread(libmsgque::MqS*,
> libmsgque::MqFactoryS*, libmsgque::MqBufferLS**, libmsgque::MqBufferLS**,
> char const*, int, libmsgque::MqIdS*) (sys.cc:562)
> ==67406==by 0x5057E6F: libmsgque::pIoStartServer(libmsgque::MqIoS*,
> libmsgque::IoStartServerE, libmsgque::MqSockS*, libmsgque::MqIdS*)
> (io.cc:692)
> ==67406==by 0x5053294: libmsgque::GenericServer(libmsgque::GenericS*,
> sockaddr*, unsigned int) (generic_io.cc:155)
> ==67406==by 0x5048FE9: libmsgque::UdsServer(libmsgque::UdsS*)
> (uds_io.cc:129)
> ==67406==by 0x505421E: libmsgque::pIoCreate(libmsgque::MqS*,
> libmsgque::MqIoS**) (io.cc:95)
> ==67406==by 0x5083507: libmsgque::MqLinkCreate(libmsgque::MqS*,
> libmsgque::MqBufferLS*) (link.cc:1104)
> ==67406==by 0x5084730: libmsgque::MqLinkDefault(libmsgque::MqS*,
> libmsgque::MqBufferLS*) (link.cc:1256)
> ==67406==by 0x5082279: libmsgque::MqLinkCreate(libmsgque::MqS*,
> libmsgque::MqBufferLS*) (link.cc:971)
> ==67406==by 0x50B3ACD:

[Bug c++/85471] closing a "thread" in "C++" using "pthread_exit(NULL)" creates a "SIGABRT"

2018-06-16 Thread aotto1...@t-online.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85471

--- Comment #4 from Andreas Otto  ---
change my C++ wrapper from "embedded data" (large amount of data) to just an
embedded pointer (only 8byte pointer in the C++ class)

→ the error is still there…

==57730== Process terminating with default action of signal 6 (SIGABRT)
==57730==at 0x6BA2F67: raise (raise.c:55)
==57730==by 0x6BA4339: abort (abort.c:78)
==57730==by 0x4178DD: _Unwind_SetGR (unwind-dw2.c:273)
==57730==by 0x409B8C: __gxx_personality_v0 (eh_personality.cc:712)
==57730==by 0x72AC4A4: _Unwind_ForcedUnwind_Phase2 (unwind.inc:175)
==57730==by 0x72ACA64: _Unwind_ForcedUnwind (unwind.inc:207)
==57730==by 0x696098F: __pthread_unwind (unwind.c:126)
==57730==by 0x695A8B4: __do_cancel (pthreadP.h:283)
==57730==by 0x695A8B4: pthread_exit (pthread_exit.c:28)
==57730==by 0x506554E: libmsgque::SysExit(int, int) (sys.cc:1000)
==57730==by 0x5059987: libmsgque::MqSysExit(int, int) (msgque.h:2038)
==57730==by 0x505B4F8: libmsgque::MqExitP(libmsgque::MqS*, char const*,
char const*) (msgque.cc:440)
==57730==by 0x50B2FAA: ccmsgque::MqC::ExitP(char const*, char const*)
(MqC.cc:380)
==57730==by 0x405EF7: Filter6::EXIT() (Filter6.cc:80)
==57730==by 0x5099A15: ccmsgque::MqC::ProcCall(libmsgque::MqS*, void*)
(ccmisc.cc:50)
==57730==by 0x5043DA3: libmsgque::MqCallbackCall(libmsgque::MqS*,
libmsgque::MqCallbackS) (msgque_private.h:326)
==57730==by 0x5045368: libmsgque::pTokenInvoke(libmsgque::pTokenS const*)
(token.cc:342)
==57730==by 0x507836C: libmsgque::pServiceStart(libmsgque::MqS*,
libmsgque::MqErrorE (*)(void*, libmsgque::MqS**, libmsgque::MqEnvS*), void*)
(service.cc:244)
==57730==by 0x502D33B: libmsgque::pEventStart(libmsgque::MqS*,
libmsgque::MqEventS*, timeval const*) (event.cc:287)
==57730==by 0x5055AD3: libmsgque::pIoSelectStart(libmsgque::MqIoS*, timeval
const*) (io.cc:267)
==57730==by 0x5078B3E: libmsgque::MqProcessEvent(libmsgque::MqS*, long,
libmsgque::MqWaitOnEventE) (service.cc:377)
==57730==by 0x5063F70:
libmsgque::MqSysServerThreadMain(libmsgque::MqSysServerThreadMainS*)
(sys.cc:488)
==57730==by 0x5063FB7: libmsgque::sSysServerThreadInit(void*) (sys.cc:502)
==57730==by 0x6959723: start_thread (pthread_create.c:457)
==57730==by 0x6C5AE8C: clone (clone.S:109)
==57730== 
==57730== HEAP SUMMARY:
==57730== in use at exit: 160,370 bytes in 184 blocks
==57730==   total heap usage: 940 allocs, 756 frees, 677,695 bytes allocated
==57730== 
==57922== 
==57922== HEAP SUMMARY:
==57922== in use at exit: 72,944 bytes in 4 blocks
==57922==   total heap usage: 487 allocs, 483 frees, 273,097 bytes allocated
==57922== 
==57922== LEAK SUMMARY:
==57922==definitely lost: 0 bytes in 0 blocks
==57922==indirectly lost: 0 bytes in 0 blocks
==57922==  possibly lost: 0 bytes in 0 blocks
==57922==still reachable: 72,944 bytes in 4 blocks
==57922== suppressed: 0 bytes in 0 blocks
==57922== Rerun with --leak-check=full to see details of leaked memory
==57922== 
==57922== For counts of detected and suppressed errors, rerun with: -v
==57922== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==57730== LEAK SUMMARY:


but I have additional "leakcheck" data…


 trans2-3-TE2-init-(3|binary|uds|cc.uds.thread) start
==67406== 672 bytes in 2 blocks are possibly lost in loss record 131 of 151
==67406==at 0x4C2C240: calloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==67406==by 0x40119E1: allocate_dtv (dl-tls.c:322)
==67406==by 0x401223D: _dl_allocate_tls (dl-tls.c:539)
==67406==by 0x695A180: allocate_stack (allocatestack.c:580)
==67406==by 0x695A180: pthread_create@@GLIBC_2.2.5 (pthread_create.c:654)
==67406==by 0x5064231: libmsgque::SysServerThread(libmsgque::MqS*,
libmsgque::MqFactoryS*, libmsgque::MqBufferLS**, libmsgque::MqBufferLS**, char
const*, int, libmsgque::MqIdS*) (sys.cc:562)
==67406==by 0x5057E6F: libmsgque::pIoStartServer(libmsgque::MqIoS*,
libmsgque::IoStartServerE, libmsgque::MqSockS*, libmsgque::MqIdS*) (io.cc:692)
==67406==by 0x5053294: libmsgque::GenericServer(libmsgque::GenericS*,
sockaddr*, unsigned int) (generic_io.cc:155)
==67406==by 0x5048FE9: libmsgque::UdsServer(libmsgque::UdsS*)
(uds_io.cc:129)
==67406==by 0x505421E: libmsgque::pIoCreate(libmsgque::MqS*,
libmsgque::MqIoS**) (io.cc:95)
==67406==by 0x5083507: libmsgque::MqLinkCreate(libmsgque::MqS*,
libmsgque::MqBufferLS*) (link.cc:1104)
==67406==by 0x5084730: libmsgque::MqLinkDefault(libmsgque::MqS*,
libmsgque::MqBufferLS*) (link.cc:1256)
==67406==by 0x5082279: libmsgque::MqLinkCreate(libmsgque::MqS*,
libmsgque::MqBufferLS*) (link.cc:971)
==67406==by 0x50B3ACD: ccmsgque::MqC::LinkCreate(ccmsgque::MqBufferLC*)
(MqC.cc:414)
==67406==by 0x5095DE2: ccmsgque::MqC::LinkCreate(ccmsgque::MqBufferLC)
(ccmsgque.cc:151)
==67406==by 0x40498B: main (Filter6.cc:176)
==67406==

[Bug c++/85471] closing a "thread" in "C++" using "pthread_exit(NULL)" creates a "SIGABRT"

2018-04-19 Thread redi at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85471

--- Comment #3 from Jonathan Wakely  ---
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 
#include 

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 
#include 

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.

[Bug c++/85471] closing a "thread" in "C++" using "pthread_exit(NULL)" creates a "SIGABRT"

2018-04-19 Thread aotto1...@t-online.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85471

--- Comment #2 from Andreas Otto  ---
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…

it is possible you send me a hint to create a better error output for you… for
me it would be perfect if the GCC part of the error could be MORE specific
about the real reason of the SIGABRT

thanks for your work.

[Bug c++/85471] closing a "thread" in "C++" using "pthread_exit(NULL)" creates a "SIGABRT"

2018-04-19 Thread redi at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85471

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-04-19
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Please provide a test case.

https://gcc.gnu.org/bugs/