Tested on muta.hppa.dev.gentoo.org As a mistake on my part, I have tried to emerge "app-shells/bash[mem-scramble]" as part of "tatt" run for stable bug. After successful emerge of app-shells/bash-5.1_p16, the very next runs of emerge were failing in very weird places, mainly during pkg_setup, with seg faults like: /usr/lib/portage/python3.9/ebuild.sh: xmalloc: variables.c:4849: cannot allocate 1666 bytes (2646016 bytes allocated) /var/db/repos/gentoo/eclass/flag-o-matic.eclass: xmalloc: make_cmd.c:464: cannot allocate 24 bytes (2150400 bytes allocated) Any successive run of emerge was always failing. No build log was created for those fails! Fixed by using `emerge --root ... -a app-shells/bash` with default USE flags from outside the chroot. For now, I'm masking that USE flag on hppa.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5f94b34dfbc2c96ae99d729ea7b10011ff8dc9fa commit 5f94b34dfbc2c96ae99d729ea7b10011ff8dc9fa Author: Arthur Zamarin <arthurzam@gentoo.org> AuthorDate: 2022-02-08 18:17:07 +0000 Commit: Arthur Zamarin <arthurzam@gentoo.org> CommitDate: 2022-02-08 18:17:07 +0000 profiles/arch/hppa: mask app-shells/bash[mem-scramble] Bug: https://bugs.gentoo.org/832946 Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org> profiles/arch/hppa/package.use.mask | 4 ++++ 1 file changed, 4 insertions(+)
I started poking at this but my home HPPA box isn't going to be in action for about a month more so not had a chance to resume. USE=mem-scramble uses Bash's own malloc (no surprise there). We're failing at https://git.savannah.gnu.org/cgit/bash.git/tree/xmalloc.c?id=8868edaf2250e09c4e9a1c75ffe3274f28f38581#n93: >#if HAVE_SBRK && defined (USING_BASH_MALLOC) > allocated = findbrk (); > fatal_error (_("%s: cannot allocate %lu bytes (%lu bytes allocated)"), >func, (unsigned long)bytes, (unsigned long)allocated); >#else The implementation of findbrk looks of interest (https://git.savannah.gnu.org/cgit/bash.git/tree/xmalloc.c?id=8868edaf2250e09c4e9a1c75ffe3274f28f38581#n65): >static size_t >findbrk () >{ > FINDBRK(); > return (char *)sbrk (0) - (char *)lbreak; >} More on sbrk at https://stackoverflow.com/a/19703860. It's not clear to me that this is stack-direction independent, but I'm not sure: https://stackoverflow.com/questions/21399590/c-sbrk-addresses-ascending-or-descending.
Not a toolchain problem.