Description of problem: When loading the library using dlopen() error appears: "/usr/lib64/libtcmalloc.so.4: cannot allocate memory in static TLS block" Working dlopen() is required for wiredtiger-python, which is python (using swig) adapter for libwiredtiger.so. libwiredtiger.so requires libtcmalloc.so. So loading either libtcmalloc.so or libiwiredtiger.so causes this error. How reproducible: - It works for me on x86_64 and ppc64le. But failure occurs on aarch64 and s390x. - F25 is working. F26 and F27 is failing. Steps to Reproduce: 1. $ cat dlopen.c #include <stdlib.h> #include <stdio.h> #include <dlfcn.h> int main(int argc, char **argv) { void *handle; handle = dlopen ("/usr/lib64/libtcmalloc.so.4", RTLD_LAZY); if (!handle) { fputs (dlerror(), stderr); exit(1); } dlclose(handle); } 2. $ gcc dlopen.c -ldl 3. $ ./a.out
I've disabled using of tcmalloc in wiredtiger now. But it would be great to be able to use it again.
I feel like this is either a glibc/gcc bug or something specific to those architectures. That said, this code is likely triggering things: #if defined(HAVE___ATTRIBUTE__) && defined(HAVE_TLS) #define ATTR_INITIAL_EXEC __attribute__ ((tls_model ("initial-exec"))) #else #define ATTR_INITIAL_EXEC #endif To test this (I do not have an aarch64 or s390x system handy), I've made a scratch build of gperftools which adds a configure flag (--disable-general-dynamic-tls) that prevents the __attribute__ ((tls_model ("initial-exec"))) from being used. I am only passing that configure flag on s390x and aarch64, since you report that dlopen works properly on the other architectures. Please download and test this build and let me know if this resolves the issue: https://koji.fedoraproject.org/koji/taskinfo?taskID=21446103
Thank you. I am very sorry that I get back to this issue so late. Scratch build deleted already. Could you please do another one?
I'm 99% sure this is correct, so I'm just going to roll this into the next update. Please test and let me know.
gperftools-2.6.1-5.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-d7884ae0b9
gperftools-2.6.1-5.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-236ad80b82
gperftools-2.6.1-5.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-236ad80b82
gperftools-2.6.1-5.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-d7884ae0b9
It solved the problem for me only when using libtcmalloc_minimal.so ... What is different in libtcmalloc_minimal.so?
gperftools-2.6.1-5.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
gperftools-2.6.1-5.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.