rustc segfaults with mimalloc

[thomasfsteeples]

I have rustc installed via rustup. Additionally, I'm using mimalloc as my allocator, loaded with the LD_PRELOAD environment variable. Taking a hello-world program and saving it as main.rs, running rustc main.rs yields:

fish: Job 1, 'rustc main.rs' terminated by signal SIGSEGV (Address boundary error)

Running gdb -ex run --args rustc main.rs gives me the following output:

Reading symbols from rustc...
Starting program: /home/[REDACTED]/.cargo/bin/rustc main.rs
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
process 8078 is executing new program: /home/[REDACTED]/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustc
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7fffee1ff640 (LWP 8089)]

Thread 2 "rustc" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffee1ff640 (LWP 8089)]
free (ptr=0x50ddf412300) at ../jemalloc/src/jemalloc.c:2393
2393	../jemalloc/src/jemalloc.c: No such file or directory.

If instead, I run env LD_PRELOAD="" rustc main.rs, then everything works as expected. I would expect rustc to work with a custom allocator.

Meta

rustc --version --verbose:

rustc 1.52.0 (88f19c6da 2021-05-03)
binary: rustc
commit-hash: 88f19c6dab716c6281af7602e30f413e809c5974
commit-date: 2021-05-03
host: x86_64-unknown-linux-gnu
release: 1.52.0
LLVM version: 12.0.0

Running on Arch Linux 5.11.6

[nagisa]

Looks like free continues to be provided by jemalloc, so I would suspect that LD_PRELOADing mimalloc is not going the entire way to override the allocation/deallocation symbols everywhere.

I suspect its going to have something to do with the fact that jemalloc is likely statically-ish linked.

I would expect rustc to work with a custom allocator.

The only way I can see to satisfy this expectation is for rustc to be built with the system allocator (cf. jemalloc = false option in config.toml). For that reason I strongly suspect that we won't consider allocator replacement via LD_PRELOAD to be a supported use-case for binaries built and distributed by our infrastructure.