This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libstdc++/54018] New: std::uncaught_exception hangs in pthread created during global initialization from dlopen


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: unassigned@gcc.gnu.org
        ReportedBy: werkt0@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]