Hide Forgot
+++ This bug was initially created as a clone of Bug #1984075 +++ glibc 2.34 tries to use the clone3 system call to create threads. This change is already included in builds glibc-2.33.9000-44.fc35 and later (only in Koji, not tagged into the buildroot/compose). Currently, valgrind prints a warning for every clone3 system call, which can be reproduced e.g. with Python: $ valgrind python3 ==3260== Memcheck, a memory error detector ==3260== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==3260== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info ==3260== Command: python3 ==3260== Python 3.10.0b4 (default, Jul 16 2021, 00:00:00) [GCC 11.1.1 20210623 (Red Hat 11.1.1-6)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import threading >>> threading.Thread(None, lambda: print("Thread is running")).start() --3260-- WARNING: unhandled amd64-linux syscall: 435 --3260-- You may be able to write your own handler. --3260-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --3260-- Nevertheless we consider this a bug. Please report --3260-- it at http://valgrind.org/support/bug_reports.html. Thread is running >>> The thread is still launched, but the warning is annoying.
Upstream bugzilla contains a workaround making clone3 produce ENOSYS so glibc falls back on clone. Currently being tested in Fedora rawhide.
Preverified that the bug is fixed in the latest build valgrind-3.17.0-10.el9 and glibc-2.33.9000-55.el9. With valgrind-3.17.0-8.el9: [root@sweetpig-8 ~]# valgrind python3 -c "import threading; threading.Thread(None, lambda:print('Thread is running')).start()" ==20786== Memcheck, a memory error detector ==20786== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==20786== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info ==20786== Command: python3 -c import\ threading;\ threading.Thread(None,\ lambda:print('Thread\ is\ running')).start() ==20786== --20786-- WARNING: unhandled amd64-linux syscall: 435 --20786-- You may be able to write your own handler. --20786-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --20786-- Nevertheless we consider this a bug. Please report --20786-- it at http://valgrind.org/support/bug_reports.html. Thread is running ==20786== ==20786== HEAP SUMMARY: ==20786== in use at exit: 839,345 bytes in 8,158 blocks ==20786== total heap usage: 38,978 allocs, 30,820 frees, 5,531,067 bytes allocated ==20786== ==20786== LEAK SUMMARY: ==20786== definitely lost: 0 bytes in 0 blocks ==20786== indirectly lost: 0 bytes in 0 blocks ==20786== possibly lost: 830,780 bytes in 8,101 blocks ==20786== still reachable: 8,565 bytes in 57 blocks ==20786== suppressed: 0 bytes in 0 blocks ==20786== Rerun with --leak-check=full to see details of leaked memory ==20786== ==20786== For lists of detected and suppressed errors, rerun with: -s ==20786== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) With valgrind-3.17.0-10.el9: valgrind python3 -c "import threading; threading.Thread(None, lambda:print('Thread is running')).start()" ==20972== Memcheck, a memory error detector ==20972== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==20972== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info ==20972== Command: python3 -c import\ threading;\ threading.Thread(None,\ lambda:print('Thread\ is\ running')).start() ==20972== Thread is running ==20972== ==20972== HEAP SUMMARY: ==20972== in use at exit: 839,345 bytes in 8,158 blocks ==20972== total heap usage: 38,972 allocs, 30,814 frees, 5,530,747 bytes allocated ==20972== ==20972== LEAK SUMMARY: ==20972== definitely lost: 0 bytes in 0 blocks ==20972== indirectly lost: 0 bytes in 0 blocks ==20972== possibly lost: 830,780 bytes in 8,101 blocks ==20972== still reachable: 8,565 bytes in 57 blocks ==20972== suppressed: 0 bytes in 0 blocks ==20972== Rerun with --leak-check=full to see details of leaked memory ==20972== ==20972== For lists of detected and suppressed errors, rerun with: -s ==20972== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Also a minor note: this bug affects only x86_64. The rest of archs keep using clone() syscall after glibc2.34 update.
Regression testing on valgrind-3.17.0-11.el9 looks good.