Your message dated Mon, 1 Jul 2024 23:42:17 +0200
with message-id <1c247a9e-dccf-4e1f-b12b-25de89cbd...@svario.it>
and subject line Re: Bug#522849: Bash xrealloc randomly fails
has caused the Debian Bug report #522849,
regarding Bash xrealloc randomly fails
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
522849: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522849
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: bash
Version: 3.2-4
I'm on an x86_64 machine.
I believe this bug is due to Bash's builtin malloc implementation only
supporting sbrk() and not mmap() to get memory.
I'd like to suggest that the correct resolution of this bug is to
disable bash's builtin malloc and simply use glibc's. I'm not sure
whether or not this should be considered a kernel bug as well.
More details:
bash fails with a message like:
xrealloc: ../bash/general.c:888: cannot reallocate 262144 bytes (0
bytes allocated)
(not always that exact line in the source, but that particular failure
line is pretty common, I expect because it's allocating a lot of
memory).
This started happening after an upgrade from kernel 2.6.22 to kernel
2.6.26 (non-debian kernels). I've tracked it down to this new feature:
<<<
1.9. BRK and PIE executable randomization
Exec-shield is a Red Hat that was started in 2003 by Red Hat to
implement several security protections and is mainly used in Red Hat and
Fedora. Many features have already been merged lot of time ago, but not
all of them. In 2.6.25 two of them are being merged: brk() randomization
and PIE executable randomization. Those two features should make the
address space randomization on i386 and x86_64 complete.
http://kernelnewbies.org/Linux_2_6_25#head-fc71477174376b69ac7c3cd153ed513d25bf2cae
<<<
The randomized brk placement is disableable via "echo 1 > /proc/sys/
kernel/randomize_va_space". When that value is set to 1, the failures
stop happening. When it's set to 2 (default value for my kernel), bash
randomly fails with the above error.
It seems that what is happening is that the randomized heap placement
is sometimes causing there to be shared libraries mapped close enough
after the heap such that there's not enough room for expansion. And
since bash's malloc can only use sbrk memory, it simply fails at that
point.
I'll also note that the placement of libraries in low memory around
the heap only happens if you've set a stack size ulimit, e.g. "ulimit -
S -s 10240".
Here's /proc/<pid>/maps of a process shortly before it fails:
00110000-0012b000 r-xp 00000000 08:04
41272590 /lib/ld-2.7.so
0032a000-0032c000 rw-p 0001a000 08:04
41272590 /lib/ld-2.7.so
00400000-004ba000 r-xp 00000000 08:04
41271303 /bin/bash
006b9000-006c3000 rw-p 000b9000 08:04
41271303 /bin/bash
006c3000-006c8000 rw-p 006c3000 00:00 0
006c8000-00702000 r-xp 00000000 08:04
41272640 /lib/libncurses.so.5.6
00702000-00902000 ---p 0003a000 08:04
41272640 /lib/libncurses.so.5.6
00902000-00907000 rw-p 0003a000 08:04
41272640 /lib/libncurses.so.5.6
00907000-00909000 r-xp 00000000 08:04
41272625 /lib/libdl-2.7.so
00909000-00b09000 ---p 00002000 08:04
41272625 /lib/libdl-2.7.so
00b09000-00b0b000 rw-p 00002000 08:04
41272625 /lib/libdl-2.7.so
00b0b000-00c49000 r-xp 00000000 08:04
41272608 /lib/libc-2.7.so
00c49000-00e49000 ---p 0013e000 08:04
41272608 /lib/libc-2.7.so
00e49000-00e4c000 r--p 0013e000 08:04
41272608 /lib/libc-2.7.so
00e4c000-00e4e000 rw-p 00141000 08:04
41272608 /lib/libc-2.7.so
00e4e000-00e53000 rw-p 00e4e000 00:00 0
00e53000-00e5a000 r-xp 00000000 08:04
41272645 /lib/libnss_compat-2.7.so
00e5a000-01059000 ---p 00007000 08:04
41272645 /lib/libnss_compat-2.7.so
01059000-0105b000 rw-p 00006000 08:04
41272645 /lib/libnss_compat-2.7.so
0105b000-01064000 r-xp 00000000 08:04
41272653 /lib/libnss_nis-2.7.so
01064000-01264000 ---p 00009000 08:04
41272653 /lib/libnss_nis-2.7.so
01264000-01266000 rw-p 00009000 08:04
41272653 /lib/libnss_nis-2.7.so
01266000-01270000 r-xp 00000000 08:04
41272649 /lib/libnss_files-2.7.so
01270000-0146f000 ---p 0000a000 08:04
41272649 /lib/libnss_files-2.7.so
0146f000-01471000 rw-p 00009000 08:04
41272649 /lib/libnss_files-2.7.so
01471000-01473000 r-xp 00000000 08:04
41320632 /usr/lib/gconv/ISO8859-1.so
01473000-01672000 ---p 00002000 08:04
41320632 /usr/lib/gconv/ISO8859-1.so
01672000-01674000 rw-p 00001000 08:04
41320632 /usr/lib/gconv/ISO8859-1.so
01e9d000-01ead000 rw-p 01e9d000 00:00
0 [heap]
01f24000-01f38000 r-xp 00000000 08:04
41272643 /lib/libnsl-2.7.so
01f38000-02137000 ---p 00014000 08:04
41272643 /lib/libnsl-2.7.so
02137000-02139000 rw-p 00013000 08:04
41272643 /lib/libnsl-2.7.so
02139000-0213b000 rw-p 02139000 00:00 0
7f88235f9000-7f8823600000 r--s 00000000 08:04
41320688 /usr/lib/gconv/gconv-modules.cache
7f8823600000-7f8823775000 r--p 00000000 08:04
41353218 /usr/lib/locale/locale-archive
7f8823775000-7f8823777000 rw-p 7f8823775000 00:00 0
7f882377d000-7f8823780000 rw-p 7f882377d000 00:00 0
7fff2b76b000-7fff2b780000 rw-p 7ffffffea000 00:00
0 [stack]
7fff2b7ff000-7fff2b800000 r-xp 7fff2b7ff000 00:00
0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00
0 [vsyscall]
--- End Message ---
--- Begin Message ---
Version: 4.4.18-2
On Mon, 6 Apr 2009 18:25:05 -0400 James Y Knight <f...@fuhm.net> wrote:
I believe this bug is due to Bash's builtin malloc implementation only
supporting sbrk() and not mmap() to get memory.
Since version 4.4.18-2 Debian's bash is compiled using
--without-bash-malloc, so this error should not affect it anymore.
--
Gioele Barabucci
--- End Message ---
