http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54018
Bug #: 54018
Summary: std::uncaught_exception hangs in pthread created
during global initialization from dlopen
Classification: Unclassified
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wer...@gmail.com
Created attachment 27824
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27824
Reproducer for hang of std::uncaught_exception during thread join in global
initialization from dlopen
OS: Red Hat Enterprise Linux Server release 6.2 (Santiago)
gcc/libstdc++: RHEL6's 4.4.6-3.el6.x86_64
glibc: RHEL6's 2.12-1.47.el6_2.12.x86_64
If std::uncaught_exception is called from the routine of a pthread created
during global initialization initiated via dlopen, it hangs indefinitely while
waiting for the thread to complete.
I have attached a simple reproducer. Looking at the source for libstdc++ and
the backtrace during the hang, it is fairly obvious that ld-linux-x86-64.so.2
is holding a mutex needed for tls operations during __cxa_get_globals during
dlopen. If the thread is unjoined (detached or ignored) during global
initialization from dlopen, it will successfully acquire a lock from tls and
return from uncaught_exception.
This is a regression from our other operating environment:
gcc/libstdc++: 4.3.2
glibc: 2.5
Wherein running the 'main' program provided does not hang. I'm unsure whether
this was introduced by glibc/ld.so changes or a change to libstdc++. I'll
accept if this behavior is unsupported, as it does throw together dlopen,
pthreads, and global initialization rather unceremoniously, but I'll remain
optimistic that this is a genuine regression of previously safe behavior.
Regards,
-George
