On 2021-10-23 08:12, Johannes Schauer Marin Rodrigues wrote:
> Package: fakechroot
> Version: 2.20.1-1
> Severity: normal
> Control: affects -1 + jemalloc
>
> Hi,
>
> libjemalloc and fakechroot do not play well together on arm64 and
> riscv64. Faidon managed to analyze the situation. It follows what they
> found out:
>
> I got a backtrace (see below) by:
> 1) attempting a normal build; killing it when it reaches t/jemalloc.t
> 2) cd test; ./t/jemalloc.t
> 3) gdb -p ($pidof cat)
>
> This is a deadlock, by malloc() being invoked in the code path for malloc().
> Something tries to malloc(), jemalloc tries to initialize itself, which in
> turn
> means trying to open() /sys/kernel/mm/transparent_hugepage/enabled, but open()
> is LD_PRELOADed to fakechroot, which tries to initialize itself, which in turn
> tries to malloc memory.
>
> I'm not entirely sure why that happens yet, or why it only happens on arm64.
> I
> believe it is unrelated to the previous bug, #918742.
The common point of arm64 and riscv64 (and a few new architectures) is
that they lack the older syscalls that can be replaced by newer one. In
that case they lack the open syscall, which can be replaced by openat.
jemalloc tries to query /sys/kernel/mm/transparent_hugepage/enabled
directly through a syscall if available, without going through glibc as
can be seen in src/pages.c:562:
| #if defined(JEMALLOC_USE_SYSCALL) && defined(SYS_open)
| int fd = (int)syscall(SYS_open,
| "/sys/kernel/mm/transparent_hugepage/enabled", O_RDONLY);
| #else
| int fd = open("/sys/kernel/mm/transparent_hugepage/enabled",
O_RDONLY);
| #endif
I guess one fix or workaround would be to add support for the SYS_openat
syscall as a fallback. Luckily this has already been done upstream:
https://github.com/jemalloc/jemalloc/commit/6924f83cb21f75e1c892d8f469500e12f1a3f5a7#diff-e2003bd99a76acf15d071c2fd49cfaeefae69debe6fc304a86f104b662da986c
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
