[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken

[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken

[b.r.longbons at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017

Ben Longbons <b.r.longbons at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |b.r.longbons at gmail dot com

--- Comment #5 from Ben Longbons <b.r.longbons at gmail dot com> ---
I just hit this in my testsuite, and it's worse than described for the dynamic
case:

if libpthread.so is dlopen'ed after libstdc++, __gthread_active_p() will *not*
become true - weak symbols are not rebound.

Note that plugins that indirectly pull in pthreads are very common in the wild.

Further, LD_PRELOAD=libpthread.so.0 does NOT help.

Thus, all C++ locks will do nothing despite the presence of multiple threads.
Correct code will experience race conditions.

Do note that, nowadays, all of the *other* symbols you're making weak are in
libc.so (for GLIBC at least, which AFAIK is the only dlopen'able pthread
implementation)

(I had falsely assumed the only danger was doing the dlopen while any lock is
held, leading to mismatched lock/unlock pairs, which would be fairly easy to
avoid)

Tested on Debian 10 (buster), with:

g++ (Debian 8.3.0-6) 8.3.0
GNU C Library (Debian GLIBC 2.28-10) stable release version 2.28.
GNU ld (GNU Binutils for Debian) 2.31.1



// link with -ldl
#include <gnu/lib-names.h>

#include <assert.h>
#include <dlfcn.h>

#include <bits/gthr.h>

int main(void)
{
    void *libpthread = dlopen(LIBPTHREAD_SO, RTLD_LAZY);
    assert (libpthread);
    assert (__gthread_active_p());
}

[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-11-23
                 CC|                            |redi at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Ben Longbons from comment #5)
> I just hit this in my testsuite, and it's worse than described for the
> dynamic case:
> 
> if libpthread.so is dlopen'ed after libstdc++, __gthread_active_p() will
> *not* become true - weak symbols are not rebound.

The problem isn't that weak symbols are not rebound (they are), it's that
__gthread_active_p stores the result of the first check in a static variable
which is initialized once and then it's value doesn't change:

  static void *const __gthread_active_ptr
    = __extension__ (void *) &GTHR_ACTIVE_PROXY;

> Note that plugins that indirectly pull in pthreads are very common in the
> wild.

At the time of writing, the main executable needs to link to libpthread, not
just the plugins. Otherwise libstdc++ won't work.

Glibc also has a history of bugs with libpthread only being loaded via dlopen.

> Further, LD_PRELOAD=libpthread.so.0 does NOT help.
> 
> Thus, all C++ locks will do nothing despite the presence of multiple
> threads. Correct code will experience race conditions.
> 
> Do note that, nowadays, all of the *other* symbols you're making weak are in
> libc.so (for GLIBC at least, which AFAIK is the only dlopen'able pthread
> implementation)

I don't think that's true at all. It's planned for a future version of glibc
though, see https://sourceware.org/legacy-ml/libc-alpha/2019-10/msg00080.html

When that happens, __gthread_active_p will always be true for glibc (and the
weak symbols won't be needed anyway).

[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ppluzhnikov at google dot com

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 87189 has been marked as a duplicate of this bug. ***

[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken with new enough glibc (GTHREAD_USE_WEAK can be defined to 0 now)

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl.tools at gmail dot com

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 114646 has been marked as a duplicate of this bug. ***

[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken with new enough glibc (GTHREAD_USE_WEAK can be defined to 0 now)

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |punitb20 at gmail dot com

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 109540 has been marked as a duplicate of this bug. ***

[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken with new enough glibc (GTHREAD_USE_WEAK can be defined to 0 now)

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed:
https://gcc.gnu.org/pipermail/gcc-cvs/2024-April/401301.html