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. Faidon (gdb) bt #0 __lll_lock_wait (futex=futex@entry=0xffff9dd604e0 <init_lock+64>, private=0) at lowlevellock.c:52 #1 0x0000ffff9d8f9070 in __GI___pthread_mutex_lock (mutex=0xffff9dd604e0 <init_lock+64>) at pthread_mutex_lock.c:80 #2 0x0000ffff9dd1c4e0 in malloc_mutex_lock_final (mutex=0xffff9dd604a0 <init_lock>) at include/jemalloc/internal/mutex.h:155 #3 je_malloc_mutex_lock_slow (mutex=mutex@entry=0xffff9dd604a0 <init_lock>) at src/mutex.c:85 #4 0x0000ffff9dce4a50 in malloc_mutex_lock (mutex=0xffff9dd604a0 <init_lock>, tsdn=0x0) at include/jemalloc/internal/mutex.h:221 #5 malloc_init_hard () at src/jemalloc.c:1740 #6 0x0000ffff9dce8650 in malloc_init () at src/jemalloc.c:210 #7 imalloc_init_check (dopts=<synthetic pointer>, sopts=<synthetic pointer>) at src/jemalloc.c:2230 #8 imalloc (dopts=<synthetic pointer>, sopts=<synthetic pointer>) at src/jemalloc.c:2261 #9 calloc (num=num@entry=6, size=size@entry=1) at src/jemalloc.c:2495 #10 0x0000ffff9ddfa020 in fakechroot_init () at ./src/libfakechroot.c:126 #11 0x0000ffff9de05c24 in fakechroot_localdir (p_path=p_path@entry=0xffff9dd3df98 "/sys/kernel/mm/transparent_hugepage/enabled") at ./src/libfakechroot.c:165 #12 0x0000ffff9de08320 in open (pathname=pathname@entry=0xffff9dd3df98 "/sys/kernel/mm/transparent_hugepage/enabled",flags=flags@entry=0) at ./src/open.c:40 #13 0x0000ffff9dd1d11c in open (__oflag=0, __path=0xffff9dd3df98 "/sys/kernel/mm/transparent_hugepage/enabled") at /usr/include/aarch64-linux-gnu/bits/fcntl2.h:53 #14 init_thp_state () at src/pages.c:567 #15 je_pages_boot () at src/pages.c:626 #16 0x0000ffff9dce4648 in malloc_init_hard_a0_locked () at src/jemalloc.c:1519 #17 0x0000ffff9dce47d4 in malloc_init_hard () at src/jemalloc.c:1751 #18 0x0000ffff9dce75ac in malloc_init () at src/jemalloc.c:210 #19 imalloc_init_check (dopts=<synthetic pointer>, sopts=<synthetic pointer>) at src/jemalloc.c:2230 #20 imalloc (dopts=<synthetic pointer>, sopts=<synthetic pointer>) at src/jemalloc.c:2261 #21 je_malloc_default (size=72704) at src/jemalloc.c:2290 #22 0x0000ffff9d9e10b4 in (anonymous namespace)::pool::pool (this=0xffff9db4d3b8 <(anonymous namespace)::emergency_pool>) at ../../../../src/libstdc++-v3/libsupc++/eh_alloc.cc:123 #23 __static_initialization_and_destruction_0 (__priority=65535, __initialize_p=1) at ../../../../src/libstdc++-v3/libsupc++/eh_alloc.cc:262 #24 _GLOBAL__sub_I_eh_alloc.cc(void) () at ../../../../src/libstdc++-v3/libsupc++/eh_alloc.cc:338 #25 0x0000ffff9de338bc in call_init (l=<optimized out>, argc=argc@entry=2, argv=argv@entry=0xffffd03cd698,env=env@entry=0xffffd03cd6b0) at dl-init.c:74 #26 0x0000ffff9de339b4 in call_init (env=0xffffd03cd6b0, argv=0xffffd03cd698, argc=2, l=<optimized out>) at dl-init.c:37 #27 _dl_init (main_map=0xffff9de59270, argc=2, argv=0xffffd03cd698, env=0xffffd03cd6b0) at dl-init.c:121 #28 0x0000ffff9de26088 in _dl_start_user () from /lib/ld-linux-aarch64.so.1 Backtrace stopped: previous frame identical to this frame (corrupt stack?)
