Package: guix;
Reported by: Ludovic Courtès <ludovic.courtes <at> inria.fr>
Date: Thu, 24 Mar 2022 21:03:01 UTC
Severity: normal
Done: Ludovic Courtès <ludo <at> gnu.org>
Bug is archived. No further changes may be made.
View this message in rfc822 format
From: Philippe SWARTVAGHER <philippe.swartvagher <at> inria.fr> To: 54557 <at> debbugs.gnu.org Subject: bug#54557: “fakechroot” execution engine doesn’t work for Bash Date: Fri, 25 Mar 2022 11:16:13 +0100
Le 24/03/2022 à 22:02, Ludovic Courtès a écrit : > Hello! > > The “fakechroot” engine fails when applied to ‘bash’: > > --8<---------------cut here---------------start------------->8--- > $ guix pack -RR bash -S /bin=bin > /gnu/store/mnbmklbvd1pk7yby0k8h26msk6z11m1m-bash-tarball-pack.tar.gz > $ (cd /tmp/pack; tar xf /gnu/store/mnbmklbvd1pk7yby0k8h26msk6z11m1m-bash-tarball-pack.tar.gz) > $ unshare -mrf sh -c 'mount -t tmpfs -o ro none /gnu/store; GUIX_EXECUTION_ENGINE=fakechroot /tmp/pack/bin/bash --version' > /tmp/pack/gnu/store/d99ykvj3axzzidygsmdmzxah4lvxd6hw-bash-5.1.8/bin//bash: out of memory to store relocation results for /tmp/pack/bin/bash > --8<---------------cut here---------------end--------------->8--- > > The message comes from ld.so. My guess is that the problem comes from > Bash’s terrible ‘malloc’ replacement: > > --8<---------------cut here---------------start------------->8--- > $ objdump -T /gnu/store/d99ykvj3axzzidygsmdmzxah4lvxd6hw-bash-5.1.8/bin/bash | grep malloc > 00000000004ae6f0 g DF .text 000000000000003b Base malloc_usable_size > 00000000004ae850 g DF .text 0000000000000009 Base malloc > 0000000000484e70 g DF .text 000000000000005b Base xmalloc > 00000000004ee020 g DO .bss 0000000000000004 Base malloc_trace_at_exit > 00000000004e8c24 g DO .data 0000000000000004 Base malloc_mmap_threshold > 0000000000484f70 g DF .text 00000000000000dd Base sh_xmalloc > 00000000004f7a04 g DO .bss 0000000000000004 Base malloc_trace > 00000000004f7a08 g DO .bss 0000000000000004 Base malloc_flags > 00000000004ae730 g DF .text 0000000000000005 Base sh_malloc > 00000000004f7a00 g DO .bss 0000000000000004 Base malloc_register > 00000000004ae660 g DF .text 000000000000000c Base _malloc_unblock_signals > 00000000004ae630 g DF .text 000000000000002e Base _malloc_block_signals > --8<---------------cut here---------------end--------------->8--- > > [Time passes…] I confirmed this hypothesis by running: > > guix pack -RR -S /bin=bin -m manifest.scm > > on this manifest: > > --8<---------------cut here---------------start------------->8--- > (use-modules (guix) (guix utils) > (guix profiles) > (gnu packages bash)) > > (define bash-sans-malloc > (package/inherit bash > (name "bash-sans-malloc") > (arguments > (substitute-keyword-arguments (package-arguments bash) > ((#:configure-flags flags ''()) > `(cons "--without-bash-malloc" ,flags)))))) > > (packages->manifest (list bash-sans-malloc)) > --8<---------------cut here---------------end--------------->8--- > > Works just fine: > > --8<---------------cut here---------------start------------->8--- > $ unshare -mrf sh -c 'mount -t tmpfs -o ro none /gnu/store; GUIX_EXECUTION_ENGINE=fakechroot /tmp/pack/bin/bash --version' > GNU bash, version 5.1.8(1)-release (x86_64-unknown-linux-gnu) > Copyright (C) 2020 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. > --8<---------------cut here---------------end--------------->8--- > > So in the end, it’s a bug report that’s kinda closed already. > > Perhaps we should build Bash ‘--without-bash-malloc’ unconditionally in > ‘core-updates’? The ‘INSTALL’ file reads: > > --8<---------------cut here---------------start------------->8--- > '--with-bash-malloc' > Use the Bash version of 'malloc' in the directory 'lib/malloc'. > This is not the same 'malloc' that appears in GNU libc, but an > older version originally derived from the 4.2 BSD 'malloc'. This > 'malloc' is very fast, but wastes some space on each allocation. > This option is enabled by default. The 'NOTES' file contains a > list of systems for which this should be turned off, and > 'configure' disables this option automatically for a number of > systems. > --8<---------------cut here---------------end--------------->8--- > > There might be other options if we want to keep it, such as changing the > ELF visibility of those symbols, but I wonder if it’s worth the effort. > > Thoughts? > > Ludo’. Hello, FTR, the --without-bash-malloc is used in the Debian bash package: apt source bash cd bash-5.1/debian grep -Irn without-bash-malloc changelog:145: * Configure the normal build --without-bash-malloc as well. changelog:1125: * Configure the static build --without-bash-malloc. changelog:1462: * Disable the GNU/kFreeBSD kludge (--without-bash-malloc). Closes: #234137. changelog:1546: * Configure --without-bash-malloc on GNU/FreeBSD (closes: #194182). changelog:1739: * Configure --without-bash-malloc. At least on hppa, this fixes an error, rules:79: --without-bash-malloc This option is also advised in Linux From Scratch: https://www.linuxfromscratch.org/lfs/view/stable/chapter08/bash.html -- Philippe
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.