Created attachment 162400 [details] Script and code to reproduce the problem SUMMARY When the application loads a shared library that calls pthread_mutex_init with its second parameter "attr" being other than NULL, then helgrind and drd die with message: undefined symbol: pthread_mutexattr_gettype STEPS TO REPRODUCE 1. extract the attached archive and execute ./run.sh 2. this will build the shared library and a program that loads it 3. then it will run the valgrind tools that die OBSERVED RESULT ./load: symbol lookup error: vgpreload_drd-amd64-linux.so: undefined symbol: ./load: symbol lookup error: vgpreload_helgrind-amd64-linux.so: undefined symbol: pthread_mutexattr_gettyp EXPECTED RESULT The script should only print debug output about activating the shared library code. SOFTWARE/OS VERSIONS Linux: Debian GNU/Linux 11 (bullseye), x86_64 Valgrind Version: 3.21.0 (compiled from source) ADDITIONAL INFORMATION I guess the problem is that the interceptors in helgrind/hg_intercepts.c and drd/drd_pthread_intercepts.c call pthread_mutexattr_gettype, which fails to be dynamically loaded by the vgpreload_helgrind-amd64-linux.so and vgpreload_drd-amd64-linux.so libraries.
Which version of libc is this with? Do you also get the problem if you don't use -Wl,-init,activate and you call activate via dlsym?
(In reply to Paul Floyd from comment #1) > Which version of libc is this with? $ ldd --version | head -n 1 ldd (Debian GLIBC 2.31-13+deb11u7) 2.31 > Do you also get the problem if you don't use -Wl,-init,activate and you call > activate via dlsym? Yes, I get exactly the same problem when explicitly calling a function from the loaded shared library.
As a workaround: export LD_PRELOAD=/lib64/libpthread.so.0 (or whatever is appropriate for your platform). The problem is that the tools do not link with libpthread but they assume that the client exe does. I'm not yet sure why the dlopen isn't making pthread_mutexattr_gettype available.