Hongxu Jia added the comment: 3. Analysis 1) The multiprocessing invokes named semaphore in C library (sem_open/sem_post/sem_getvalue/sem_unlink in ./Modules/_multiprocessing/semaphore.c)
2) The glibc defines two different sem_getvalue since the following commit. https://sourceware.org/git/?p=glibc.git;a=blob;f=nptl/sem_getvalue.c;h=1432cc795ece84d5bf31c7e5cafe01cc1a09d98d;hb=042e1521c794a945edc43b5bfa7e69ad70420524 The `__new_sem_getvalue' is the sem_getvalue@@GLIBC_2.1 which work with named semaphore `sem_open' The `__old_sem_getvalue' is the old version sem_getvalue@GLIBC_2.0 which work with unamed semaphore `sem_init' In 32-bit C library, it provides both of them. $ nm -g /lib/i386-linux-gnu/libpthread-2.23.so 0000df30 T sem_getvalue@GLIBC_2.0 0000df10 T sem_getvalue@@GLIBC_2.1 3) In multiprocessing, it invokes sem_open, so sem_getvalue@@GLIBC_2.1 is supposed. If `-pthread' or `-lpthread' not passed to gcc, the compiled _multiprocessing dynamic library could not explicitly linked to sem_getvalue@@GLIBC_2.1 $ nm -g ./build/lib.linux-x86_64-3.7/_multiprocessing.cpython-37m-i386-linux-gnu.so U sem_getvalue U sem_open If `-pthread' or `-lpthread' passed to gcc: $ nm -g ./build/lib.linux-x86_64-3.7/_multiprocessing.cpython-37m-i386-linux-gnu.so U sem_getvalue@@GLIBC_2.1 U sem_open@@GLIBC_2.1.1 4) On 32-bit OS, the multiprocessing was incorrectly linked to sem_getvalue@GLIBC_2.0 which caused the issue. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31171> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com