emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#54557: closed (“fakechroot” execution engine doesn’t work for Bash)


From: GNU bug Tracking System
Subject: bug#54557: closed (“fakechroot” execution engine doesn’t work for Bash)
Date: Mon, 28 Mar 2022 10:07:01 +0000

Your message dated Mon, 28 Mar 2022 12:06:20 +0200
with message-id <87r16m4cir.fsf@gnu.org>
and subject line Re: bug#54557: “fakechroot” execution engine doesn’t work for 
Bash
has caused the debbugs.gnu.org bug report #54557,
regarding “fakechroot” execution engine doesn’t work for Bash
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
54557: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=54557
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: “fakechroot” execution engine doesn’t work for Bash Date: Thu, 24 Mar 2022 22:02:00 +0100 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
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’.



--- End Message ---
--- Begin Message --- Subject: Re: bug#54557: “fakechroot” execution engine doesn’t work for Bash Date: Mon, 28 Mar 2022 12:06:20 +0200 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> I'd be OK with --without-bash-malloc; it seems we'll pay a bit in terms
> of Bash performance in exchange for better memory usage.  It also brings
> benefits such as solving this issue and may benefit from
> advances/bugfixes to glibc's malloc in the future, if there are any.

We might actually benefit from the improvements made in glibc’s malloc
over the years (it’s more actively developed than that of Bash), who
knows.

Anyway, pushed to ‘core-updates’ as
c6b5161e97ed1010d61331874b09c3231af3b1f9.

Thanks,
Ludo’.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]