Alexey Izbyshev <izbys...@ispras.ru> added the comment:
I've encountered this issue too. My use case was a 32-bit Python on a 64-bit CentOS system, and my understanding of the issue was that 64-bit libgcc_s is somehow counted as a "provider" of libgcc_s for 32-bit libc by the package manager, so 32-bit libgcc_s is never installed even when "yum install glibc.i686" is used because everything seems "already OK": $ yum deplist glibc ... dependency: libgcc provider: libgcc.x86_64 4.1.2-55.el5 provider: libgcc.i386 4.1.2-55.el5 ... (The above is for CentOS 5, but at the time I tested 6 and 7 as well, with the same result). But I suggest not to dismiss this issue as a packaging bug. Glibc needs libgcc_s for pthread_exit() because it's implemented in terms of pthread_cancel(), and the latter wants to do stack unwinding (probably to cleanup resources for each stack frame). But the code for unwinding lives in libgcc_s. The non-intuitive thing here is that glibc tried to optimize this dependency by dlopen'ing libgcc_s when pthread_cancel() is called instead of making it a startup dependency. Many people consider this a terrible design choice since your program can now fail at an arbitrary moment due to dlopen() failure (and missing libgcc_s is not the only possible reason[1]). Since CPython doesn't use pthread_cancel() directly, I propose a simple solution -- just `return NULL` from thread functions instead of calling pthread_exit(). The last time I looked, pthread_exit() in CPython is only called from top frames of the threads, so a direct `return` should suffice. If the top-level thread function simply returns, no stack unwinding is needed, so glibc never uses its cancellation machinery. I've tested that this solution worked at the time (for 3.8 I think), and the test suite passed. If there is interest in going this way, I can test again. [1] https://www.sourceware.org/bugzilla/show_bug.cgi?id=13119 ---------- nosy: +izbyshev _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue42888> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
