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 *) >HR_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).
