14.07.2023 21:34, Thorsten Glaser wrote: ..
And, indeed, the combination of klibc-sKNr1Fw-Rh9G1FYpGCXRnrwmP2A.so and fstype from 2.0.4-2 (jessie) also fails, so you have something that can reliably be used in bisect tests I think.
Ok, this works. The bisection points to this commit between qemu v4.2.0 and v5.0.0: https://gitlab.com/qemu-project/qemu/-/commit/6fd5944980f4ccee728ce34bdaffc117db50b34d commit 6fd5944980f4ccee728ce34bdaffc117db50b34d Author: Richard Henderson <richard.hender...@linaro.org> Date: Fri Jan 17 13:02:45 2020 -1000 linux-user: Reserve space for brk With bad luck, we can wind up with no space at all for brk, which will generally cause the guest malloc to fail. This bad luck is easier to come by with ET_DYN (PIE) binaries, where either the stack or the interpreter (ld.so) gets placed immediately after the main executable. But there's nothing preventing this same thing from happening with ET_EXEC (normal) binaries, during probe_guest_base(). In both cases, reserve some extra space via mmap and release it back to the system after loading the interpreter and allocating the stack. The choice of 16MB is somewhat arbitrary. It's enough for libc to get going, but without being so large that 32-bit guests or 32-bit hosts are in danger of running out of virtual address space. It is expected that libc will be able to fall back to mmap arenas after the limited brk space is exhausted. Launchpad: https://bugs.launchpad.net/qemu/+bug/1749393 Signed-off-by: Richard Henderson <richard.hender...@linaro.org> Reviewed-by: Alex Bennée <alex.ben...@linaro.org> Tested-by: Alex Bennée <alex.ben...@linaro.org> Message-Id: <20200117230245.5040-1-richard.hender...@linaro.org> Signed-off-by: Laurent Vivier <laur...@vivier.eu> Does this ring any bells? Verified on armhf. I'll bug upstream. Thanks, /mjt
