control: retitle -1 mimalloc: riscv64: build-time MMU detection causes crashes on SV48 systems control: reassign -1 src:mimalloc control: found -1 3.0.1+ds-1
Hi, On 2026-05-14 22:09, Aurelien Jarno wrote: > On 2026-05-14 13:02, Aurelien Jarno wrote: > > Hi, > > > > On 2026-05-14 01:02, Peter Green wrote: > > > found 1136400 0.1.40-1 > > > thanks > > > > > > I believe you've quoted the wrong part of the log, > > > quoting output from a test that is already marked as "broken". > > > > > > I belive the actual failure is. > > > > > > 142s process didn't exit successfully: `CARGO=/usr/bin/cargo > > > CARGO_MANIFEST_DIR=/usr/share/cargo/registry/libmimalloc-sys-0.1.40 > > > CARGO_MANIFEST_PATH=/usr/share/cargo/registry/libmimalloc-sys-0.1.40/Cargo.toml > > > CARGO_PKG_AUTHORS='Octavian Oncescu <[email protected]>' > > > CARGO_PKG_DESCRIPTION='Sys crate wrapping the mimalloc allocator' > > > CARGO_PKG_HOMEPAGE='' CARGO_PKG_LICENSE=MIT CARGO_PKG_LICENSE_FILE='' > > > CARGO_PKG_NAME=libmimalloc-sys CARGO_PKG_README='' > > > CARGO_PKG_REPOSITORY='https://github.com/purpleprotocol/mimalloc_rust/tree/master/libmimalloc-sys' > > > CARGO_PKG_RUST_VERSION='' CARGO_PKG_VERSION=0.1.40 > > > CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=1 > > > CARGO_PKG_VERSION_PATCH=40 CARGO_PKG_VERSION_PRE='' > > > LD_LIBRARY_PATH='/tmp/tmp.YhgzhQ6wzU/target/riscv64gc-unknown-linux-gnu/debug:/tmp/tmp.YhgzhQ6wzU/target/riscv64gc-unknown-linux-gnu/debug/deps:/usr/lib/rustlib/riscv64gc-unknown-linux-gnu/lib' > > > > > > OUT_DIR=/tmp/tmp.YhgzhQ6wzU/target/riscv64gc-unknown-linux-gnu/debug/build/libmimalloc-sys-4d9f02f6027bf000/out > > > > > > /tmp/tmp.YhgzhQ6wzU/target/riscv64gc-unknown-linux-gnu/debug/deps/libmimalloc_sys-ceadfc72acec09f8` > > > (signal: 11, SIGSEGV: invalid memory reference) > > > 142s autopkgtest [05:06:41]: test librust-libmimalloc-sys-dev:arena: > > > -----------------------] > > > > I am personally unable to reproduce the issue on two different boards, > > using JH7110 and SpacemiT K1 CPU. That said after retrying the > > autopkgtest a few time on debci (it runs fast), I have noticed the > > following pattern: > > - Tests pass on debci-10 running Linux 6.12.86+deb13-riscv64 > > - Tests fail on debci-31, debci-32 and debci-33 running Linux 6.6.88-win2030 > > > > Therefore I believe it could be a kernel or a hardware issue. I guess > > the boards running the 6.6.88-win2030 kernel are the P550 ones. > > I am able to reproduce the issue on a P550 board, either running kernel > 6.6.77, 6.12.33 or 6.12.78. I am also able to reproduce it on the same > hardware in a VM running kernel 6.12.86+deb13-riscv64. > > On the other hand I am unable to reproduce it on the riscv64 porterbox > (ricci.d.o). > > I therefore believe there is something fishy with the hardware that > needs more investigation. I finally found the issue. It is in mimalloc, which contains the following build time check: | # Check /proc/cpuinfo for an SV39 MMU and limit the virtual address bits. | # (this will skip the aligned hinting in that case. Issue #939, #949) | if (EXISTS /proc/cpuinfo) | file(STRINGS /proc/cpuinfo mi_sv39_mmu REGEX "^mmu[ \t]+:[ \t]+sv39$") | if (mi_sv39_mmu) | MESSAGE( STATUS "Set virtual address bits to 39 (SV39 MMU detected)" ) | list(APPEND mi_defines MI_DEFAULT_VIRTUAL_ADDRESS_BITS=39) | endif() | endif() Our build daemons are using a sv39 nmu: | aurel32@ricci:~$ grep ^mmu /proc/cpuinfo | head -n1 | mmu : sv39 While the P550 defaults to a sv48 nmu: | aurel32@p550:~$ grep ^mmu /proc/cpuinfo | head -n1 | mmu : sv48 Therefore libmimalloc.so.3 is built with a 39-bit virtual address space support. When the binary is run on a sv48 system, things explodes. Rebuilding libmimalloc.so.3 on the P550 enables sv48 support and things work again, even on a sv39 mmu. It's not clear to me if there is a drawback to always enable sv48 support, if yes I guess a runtime detection should be implemented. Anyway for now reassigning the bug to the correct package. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B [email protected] http://aurel32.net
