Created attachment 813778 [details] build.log I have a stable chroot where I test my packages befor push and I'm unable to update binutils and binutils-libs but I didn't understand why it it does not work.
Created attachment 813781 [details] emerge --info This is the current status of the system: chroot_qm ~ $ emerge -DuNpq world [ebuild r U ] sys-libs/binutils-libs-2.38-r2 [2.37_p1-r2] [ebuild NS ] sys-devel/binutils-2.38-r2 [2.37_p1-r2] [ebuild U ] sys-devel/gcc-11.3.0 [11.2.0] [ebuild rR ] dev-db/mariadb-10.5.16 The following packages are causing rebuilds: (sys-libs/binutils-libs-2.38-r2:0/2.38::gentoo, ebuild scheduled for merge) causes rebuilds for: (dev-db/mariadb-10.5.16:10.5/18::gentoo, ebuild scheduled for merge)
fwiw error 139 typically means a segmentation fault
(In reply to Ionen Wolkens from comment #2) > fwiw error 139 typically means a segmentation fault Could have a look at dmesg, it may show what is segfaulting and could try to rebuild that if it let you for starters (and select newer binutils, etc..)
(In reply to Ionen Wolkens from comment #3) > (In reply to Ionen Wolkens from comment #2) > > fwiw error 139 typically means a segmentation fault > Could have a look at dmesg, it may show what is segfaulting and could try to > rebuild that if it let you for starters (and select newer binutils, etc..) Indeed that's what I did :) dmesg reports: [ven set 23 16:18:52 2022] make[13012]: segfault at 7ffd2979eec0 ip 00007f1c72457077 sp 00007ffd2979eec0 error 6 in libc.so.6[7f1c72414000+16b000] I rebuilt make but I see the same failure. However if I'm going to /var/tmp/portage/sys-libs/binutils-libs-2.38-r2/work/binutils-2.38-abi_x86_64.amd64 and manually type "make" or "make --output-sync=line -j4 V=1" I don't get a segfault...
(In reply to Agostino Sarubbo from comment #4) > (In reply to Ionen Wolkens from comment #3) > > (In reply to Ionen Wolkens from comment #2) > > > fwiw error 139 typically means a segmentation fault > > Could have a look at dmesg, it may show what is segfaulting and could try to > > rebuild that if it let you for starters (and select newer binutils, etc..) > > Indeed that's what I did :) > > dmesg reports: > [ven set 23 16:18:52 2022] make[13012]: segfault at 7ffd2979eec0 ip > 00007f1c72457077 sp 00007ffd2979eec0 error 6 in > libc.so.6[7f1c72414000+16b000] > > > I rebuilt make but I see the same failure. However if I'm going to > /var/tmp/portage/sys-libs/binutils-libs-2.38-r2/work/binutils-2.38- > abi_x86_64.amd64 and manually type "make" or "make --output-sync=line -j4 > V=1" I don't get a segfault... Best idea I have, rebuild make with debug info, get a core dump, print backtrace from the core dump...
I didn't get a core dump (I have support in the kernel), however I digged a bit and I found that the issue is in the emake helper, so I modified emake to run: gdb -ex "run" -ex "bt" --args make ${MAKEOPTS} ${@} ${EXTRA_EMAKE} and I get: >>> Compiling source in /var/tmp/portage/sys-libs/binutils-libs-2.38-r2/work/binutils-2.38 ... * abi_x86_64.amd64: running multilib-minimal_abi_src_compile GNU gdb (Gentoo 11.2 vanilla) 11.2 Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://bugs.gentoo.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from make... Starting program: /usr/bin/make --output-sync=line -j4 V=1 * ACCESS DENIED: open_wr: /proc/54/task/54/mem * ACCESS DENIED: open_wr: /proc/54/task/54/mem * ACCESS DENIED: open_wr: /proc/54/task/54/mem * ACCESS DENIED: open_wr: /proc/54/task/54/mem * ACCESS DENIED: open_wr: /proc/54/task/54/mem * ACCESS DENIED: open_wr: /proc/54/task/54/mem * ACCESS DENIED: open_wr: /proc/54/task/54/mem * ACCESS DENIED: open_wr: /proc/54/task/54/mem * ACCESS DENIED: open_wr: /proc/54/task/54/mem * ACCESS DENIED: open_wr: /proc/54/task/54/mem * ACCESS DENIED: open_wr: /proc/54/task/54/mem * ACCESS DENIED: open_wr: /proc/54/task/54/mem * ACCESS DENIED: open_wr: /proc/54/task/54/mem * ACCESS DENIED: open_wr: /proc/54/task/54/mem * ACCESS DENIED: open_wr: /proc/54/task/54/mem * ACCESS DENIED: open_wr: /proc/54/task/54/mem * ACCESS DENIED: open_wr: /proc/54/task/54/mem * ACCESS DENIED: open_wr: /proc/54/task/54/mem * ACCESS DENIED: open_wr: /proc/54/task/54/mem * ACCESS DENIED: open_wr: /proc/54/task/54/mem Failed to read a valid object file image from memory. [Detaching after vfork from child process 58] [Detaching after vfork from child process 59] make: *** [Makefile:1000: all] Error 139 [Inferior 1 (process 54) exited with code 02] No stack. (gdb) quit >>> Source compiled. * ----------------------- SANDBOX ACCESS VIOLATION SUMMARY ----------------------- * LOG FILE: "/var/tmp/portage/sys-libs/binutils-libs-2.38-r2/temp/sandbox.log" * VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: open_wr S: deny P: /proc/54/task/54/mem A: /proc/54/task/54/mem R: /proc/54/task/54/mem C: gdb -ex run -ex bt --args make --output-sync=line -j4 V=1 So /proc is mounted and here is: proc on /media/dati/chroot_qm/proc type proc (rw,nosuid,nodev,noexec,relatime) and /proc/54 does not exists here. I still don't understand what happens...
Created attachment 813934 [details] strace I was able to reproduce this issue manually with the portage user. The thing that makes the problem happen is '-j4' So: "make --output-sync=line -j4" does not work "make -j4 --output-sync=line" does not work "make --output-sync=line" works for me Because of a chance I saw that /tmp was not 777, and after chmod 777 /tmp it worked. So I'm wondering if we can move this bug as "portage should check for /tmp as 777, otherwise things do not work" I asked sam's feedback on irc about.
(In reply to Agostino Sarubbo from comment #7) baselayout creates /tmp with mode 1777. systemd mounts /tmp as a tmpfs with mode 1777. Please update whatever documentation/scripts you use to create a chroot environment. I don't think it makes sense to have portage check for it; it affects many more programs than just portage.
FWIW I have been seeing the same issue (also in a gentoo chroot). It is unclear to me how this happened. I've been using this chroot for a while and am pretty sure I would've noticed if this was happening for longer. I wonder if there's something in the chroot scenario where the permission get changed unintentionally, as it seems this happened to both me and ago.
Well, no duplicates for a long time so this seems to have been fixed. Strongly suggesting something more comfortable than a bare chroot though...
