44277 2022-11-11 15:10:27 +0300 make: cannot open output sync mutex 2023-05-22 06:54:21 +0300 1 1 4 Development Sisyphus glibc-source unstable x86_64 Linux CLOSED FIXED P5 normal --- 1 iv glebfm glebfm ldv legion mikealley23 qa-sisyphus oldest_to_newest 217215 0 iv 2022-11-11 15:10:27 +0300 При пересборке cross-toolchain-* обновлённым make получаем ошибку: [...] + make -j8 make -r PARALLELMFLAGS="" -C ../glibc objdir=`pwd` all make[1]: Entering directory '/usr/src/RPM/BUILD/cross-toolchain-arm-linux-gnueabihf-20220605/glibc' make[1]: *** cannot open output sync mutex /usr/src/tmp/GmWR7CBxr: No such file or directory. Stop. make[1]: Leaving directory '/usr/src/RPM/BUILD/cross-toolchain-arm-linux-gnueabihf-20220605/glibc' make: *** [Makefile:9: all] Error 2 [...] Ошибка прекрасно воспроизводится в локальном hasher на моём рабочем ноуте (Сизиф). 217216 1 iv 2022-11-11 15:12:15 +0300 Запустил под strace'ом и вижу такое: [builder@localhost obj_glibc]$ grep /usr/src/tmp/Gmhy *strace* the_make.strace.2131235:11:00:33.693720 openat(AT_FDCWD, "/usr/src/tmp/Gmhyxom8", O_RDWR|O_CREAT|O_EXCL, 0600) = 5 the_make.strace.2131235:11:00:33.723026 unlink("/usr/src/tmp/Gmhyxom8") = 0 the_make.strace.2131236:11:00:33.702617 openat(AT_FDCWD, "/usr/src/tmp/Gmhyxom8", O_WRONLY) = 3 the_make.strace.2131236:11:00:33.702734 openat(AT_FDCWD, "/usr/src/tmp/Gmhyxom8", O_WRONLY) = 4 the_make.strace.2131236:11:00:33.722006 openat(AT_FDCWD, "/usr/src/tmp/Gmhyxom8r", O_WRONLY) = -1 ENOENT (No such file or directory) Откуда взялся это 'r' в конце? 217220 2 legion 2022-11-11 15:24:53 +0300 похоже на use-after-free или просто ошибка индекса буфера. 217221 3 iv 2022-11-11 15:33:37 +0300 Совсем забыл: $ rpm -qa make make-4.4.0-alt1.x86_64 217222 4 iv 2022-11-11 15:35:07 +0300 (In reply to Alexey Gladkov from comment #2) > похоже на use-after-free или просто ошибка индекса буфера. Угу. Я пробовал запускать под valgrind'ом, ничего интересного. 217227 5 legion 2022-11-11 15:39:45 +0300 Сообщение отсюда: https://git.altlinux.org/gears/m/make.git?p=make.git;a=blob;f=make/src/posixos.c#l668 217228 6 iv 2022-11-11 15:42:49 +0300 (In reply to Ivan A. Melnikov from comment #0) > При пересборке cross-toolchain-* обновлённым make получаем ошибку Ещё веслее: если попытаться после этого зайти в hsh-shell и запустить make, получим другую ошибку: make[2]: *** Cannot open jobserver /usr/src/tmp/GMfifo2236197r: No such file or directory. Stop. Тоже 'r', но в другом месте. Причём этот 'r' уже присутсвует в переданных процессу MFLAGS (посмотрел на /exec в strace --ff -tt -v -s 99999). 217230 7 legion 2022-11-11 15:48:27 +0300 Возможно связанная проблема https://savannah.gnu.org/bugs/?63333 217232 8 ldv 2022-11-11 16:20:17 +0300 А это случайно не та же самая проблема, которая вылезла в glibc: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=2d7ed98add14f75041499ac189696c9bd3d757fe ? 217233 9 legion 2022-11-11 16:21:28 +0300 -MAKEFLAGS := $(MAKEFLAGS)r +MAKEFLAGS := $(MAKEFLAGS) -r очень похоже. 217240 10 ldv 2022-11-11 16:44:11 +0300 Тогда это надо в пакетах исправлять. 217241 11 glebfm 2022-11-11 16:52:13 +0300 Значит в этом случае проблема в glibc-source? 217247 12 iv 2022-11-11 17:53:28 +0300 (In reply to Dmitry V. Levin from comment #8) > А это случайно не та же самая проблема, которая вылезла в glibc: > https://sourceware.org/git/?p=glibc.git;a=commitdiff; > h=2d7ed98add14f75041499ac189696c9bd3d757fe > ? Да, оно, спасибо. (In reply to Gleb F-Malinovskiy from comment #11) > Значит в этом случае проблема в glibc-source? Да, пожалуй. 217263 13 repository-robot 2022-11-12 13:09:40 +0300 glibc-6:2.35.0.6.491f2e-alt2 -> sisyphus: Sat Nov 12 2022 Gleb F-Malinovskiy <glebfm@altlinux> 6:2.35.0.6.491f2e-alt2 - Backported upstream commits: + "Makerules: fix MAKEFLAGS assignment for upcoming make-4.4" to fix build with make 4.4 (thx Sergei Trofimovich) (ALT#44277); + "Avoid undefined behaviour in ibm128 implementation of llroundl" (thx Aurelien Jarno) to fix test-ibm128-llround test regression on ppc64le. - ppc64le: xfailed test-ibm128-y1 test. 226170 14 mikealley23 2023-05-22 06:54:21 +0300 The mutex merely assures that no two goroutines write/read the count at the same time; it has no control over the sequence in which those goroutines are performed. https://retrobowlgo.com/