https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189
Bug ID: 87189 Summary: libgcc/gthr-posix.h (__gthread_active_p) makes unwarranted assumptions about libpthread.a Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: ppluzhnikov at google dot com Target Milestone: --- Redirected here from GLIBC bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21777 A trivial program using pthread_key_create but not pthread_mutex_lock will crash on GLIBC, when linked statically. Current code in libgcc/gthr-posix.h: #ifdef __GLIBC__ __gthrw2(__gthrw_(__pthread_key_create), __pthread_key_create, pthread_key_create) # define GTHR_ACTIVE_PROXY __gthrw_(__pthread_key_create) assumes that if __pthread_key_create is linked in, then pthread_mutex_{lock,unlock} will also be (__gthread_active_p() returns 1). As attached test demonstrates, that is not necessarily the case. Workaround: add -Wl,-u,pthread_mutex_lock -Wl,-u,pthread_mutex_unlock to the link line. Confirmed with current GLIBC trunk (a6e8926f8d49a213a9abb1a61f6af964f612ab7f) and GCC @264043. P.S. Why would a program use pthread_key_create but not pthread_mutex_lock? Suppose you have a piece of data you want to memoize between calls to a certain function, and that the data needs to be modifiable. It's convenient to make that data thread-local, so the function is both thread-safe and parallelizable. --- test.c --- /* Link with "gcc -pthread test.c -static" */ #include <pthread.h> pthread_key_t k; int main (int argc, char *argv[]) { pthread_key_create (&k, NULL); pthread_setspecific (k, NULL); return 0; }