[Bug dynamic-link/16628] Segfault after a binary without pthread dlopen()s a library linked with pthread

fweimer at redhat dot com sourceware-bugzilla@sourceware.org
Wed Nov 30 15:05:00 GMT 2016


https://sourceware.org/bugzilla/show_bug.cgi?id=16628

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |2.25
              Flags|security?                   |security-

--- Comment #7 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Rich Felker from comment #2)
> My understanding is that this usage is explicitly unsupported. However, if
> that's the case, it should fail cleanly (with the error message in dlerror)
> rather than crashing or exiting the program so I believe this bug report is
> valid.

We have a lot of support code to load libpthread late and even go
multi-threaded after that.  dlopen of libpthread is absolutely required because
a lot of shared objects link against libpthread, and some of them are opened
from main programs which do not link against libpthread.  Whether it is
worthwhile to support going multi-thraded after dlopen is a different question,
and we certainly a substantial bugs in this area.

Some of the hairier issues have disappeared over time because we use TLS in
libc.so, so lazy initialization of TLS is gone.  But there is still substantial
work before dlopen-then-pthread_create works reliably.

Fixed in 2.25.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the Glibc-bugs mailing list