Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

miri is incorrectly built with jemalloc on some targets #133748

Open
pitust opened this issue Dec 2, 2024 · 4 comments
Open

miri is incorrectly built with jemalloc on some targets #133748

pitust opened this issue Dec 2, 2024 · 4 comments
Labels
A-miri Area: The miri tool C-bug Category: This is a bug. O-AArch64 Armv8-A or later processors in AArch64 mode T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)

Comments

@pitust
Copy link

pitust commented Dec 2, 2024

I tried to run cargo miri run in (any) workspace on Asahi Linux (which has 16k page kernels)

I expected to see this happen: The program runs under miri similarly to how rustc works

Instead, this happened:

thread 'main' panicked at src/tools/miri/cargo-miri/src/phases.rs:103:9:
failed to determine underlying rustc version of Miri (MIRI_BE_RUSTC="host" "/home/pitust/.rustup/toolchains/nightly-aarch64-unknown-linux-gnu/bin/miri"):
CommandError { stdout: "", stderr: "<jemalloc>: Unsupported system page size\n<jemalloc>: Unsupported system page size\nterminate called without an active exception\n" }
stack backtrace:
   0: rust_begin_unwind
             at /rustc/5e1440ae514d98ddfcbf1607acb64d41e07ef616/library/std/src/panicking.rs:681:5
   1: core::panicking::panic_fmt
             at /rustc/5e1440ae514d98ddfcbf1607acb64d41e07ef616/library/core/src/panicking.rs:75:14
   2: cargo_miri::phases::phase_cargo_miri::<std::env::Args>
   3: cargo_miri::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Meta

rustc --version --verbose:

rustc 1.85.0-nightly (5e1440ae5 2024-12-01)
binary: rustc
commit-hash: 5e1440ae514d98ddfcbf1607acb64d41e07ef616
commit-date: 2024-12-01
host: aarch64-unknown-linux-gnu
release: 1.85.0-nightly
LLVM version: 19.1.4
@pitust pitust added the C-bug Category: This is a bug. label Dec 2, 2024
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Dec 2, 2024
@Noratrieb
Copy link
Member

Foe context: jemalloc does not work on Linux with 16k pages, it hardcodes 4k: jemalloc/jemalloc#467
rustc works, so I suspect it's not being built with jemalloc on that target. Miris jenalloc logic is unconditional and not coupled to bootstrap jenalloc logic, which seems like the problem.

@Noratrieb Noratrieb added T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) A-miri Area: The miri tool O-AArch64 Armv8-A or later processors in AArch64 mode and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Dec 2, 2024
@Mark-Simulacrum
Copy link
Member

That issue makes it sound like jemalloc should be able to work on this system (i.e., the hardcoding was removed?) if we (or maybe jemalloc-sys?) compiled it with e.g. a 64k "page" target? At least, that's my impression of the closing comment.

@Noratrieb
Copy link
Member

Yes, we could compile jemalloc to make it work properly (and actually maybe that's what's already happening for rustc? unsure)

@marcan
Copy link

marcan commented Dec 5, 2024

Yes, 64K page mode is universal. For some vague performance-related reasons, jemalloc refuse to default to that on ARM64 and instead use 4K mode, which does not work with any other page size. You have to set --with-lg-page=16 to compile in 64K page mode, and then that will work on all targets.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-miri Area: The miri tool C-bug Category: This is a bug. O-AArch64 Armv8-A or later processors in AArch64 mode T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Projects
None yet
Development

No branches or pull requests

5 participants