Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Intermittent SIGSEGV / memory corruption under WSL2 with mimalloc 3.3.2 as Rust global allocator

Aperta
  • Qualcosa non va?
#1,430 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 5 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
8/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
c, linux, rust, wasm
Ambito
operating-systems

Direzione di ricerca

The report is a correlation from a Rust CLI under WSL2, not a minimized reproducer, so there is no failing test or named file to start from in mimalloc itself. The first useful step is to ask for a secure or debug build run with a fault handler to get symbolized frames, and to check the referenced #1287 and #1356 threads. Done would mean a reproducer or a symbolized crash that points to a specific allocator path.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

Under WSL2 (Ubuntu 24.04), setting mimalloc as the global allocator for a single-threaded Rust CLI produces intermittent process failures (SIGSEGV, Rust panics that look like heap corruption, and rare silent wrong-result exits). The same binary built against the system allocator is clean across hundreds of identical runs. Failures also persist when our application GC is replaced by a never-freeing allocator backend, which strongly suggests the collector is not required for the failures.

We are reporting this as a correlation with a controlled A/B comparison, not as a minimized pure-mimalloc reproducer. We would appreciate guidance on whether this matches a known issue in the 3.3.x line, or on how to collect a more useful dump (secure/debug build, MIMALLOC_* env, etc.).

Environment

Item Value
Host Windows + WSL2
Kernel 6.18.54.1-microsoft-standard-WSL2
Distro Ubuntu 24.04.5 LTS
Arch x86_64
Rust rustc 1.99.0
Rust crate mimalloc 0.1.52 (default-features = false)
FFI crate libmimalloc-sys 0.1.49
Embedded C MI_MALLOC_VERSION 30302 → mimalloc 3.3.2
How linked #[global_allocator] static GLOBAL: mimalloc::MiMalloc in the Rust binary
Workload Repeated release-mode compile of a large grammar corpus; memory-capped with systemd-run --user --scope -p MemoryMax=16G -p MemorySwapMax=0

We also tested with WSL [experimental] autoMemoryReclaim=dropcache both on and off. Failures occur in both configurations when mimalloc is enabled.

Method

We isolated the allocator and the application GC behind Cargo features and built four otherwise identical release binaries:

  1. app GC (gc-arena) + mimalloc
  2. never-freeing “leak” heap backend + mimalloc
  3. app GC + system allocator
  4. never-freeing heap + system allocator

Each variant ran the same capped compile workload interleaved for 60 rounds per configuration (reclaim on, then reclaim off).

Results

With autoMemoryReclaim=dropcache on
Build Failures / runs Failure modes
gc-arena + mimalloc 2 / 60 (+ 0 / 50 follow-up) exit 2 (compiler reported failure after completing work)
leak + mimalloc 1 / 60 SIGSEGV (exit 139)
gc-arena + system 0 / 110 —
leak + system 0 / 60 —
With autoMemoryReclaim off (control)
Build Failures / runs Failure modes
gc-arena + mimalloc 1 / 60 SIGSEGV
leak + mimalloc 6 / 60 4× SIGSEGV, 1× Rust panic, 1× exit 2
gc-arena + system 0 / 60 —
leak + system 0 / 60 —
Aggregate
Allocator Outcome
mimalloc (either heap backend, reclaim on or off) Multiple SIGSEGVs, one out-of-bounds panic, occasional wrong-result exits
system allocator (same) 0 failures / 230 runs

Example failure (reclaim off, leak + mimalloc)

thread 'main' panicked at src/evaluate.rs:2076:51:
index out of bounds: the len is 1 but the index is 1
Command exited with non-zero status 101

That panic is inconsistent with a deterministic logic bug in that path (same input usually succeeds). Combined with SIGSEGVs at varying RSS (~387 MB to ~13 GB), it looks more like intermittent heap corruption than a stable application bug.

Typical SIGSEGV log line:

Command terminated by signal 11
TIME 14.50 387048

We do not yet have symbolized mimalloc frames for every crash (many were run without a fault handler). Happy to re-run with a secure/debug mimalloc build if that would help.

What we ruled out (as best we can)

  • Not required: application GC. Failures continue with a never-freeing heap that contains no gc-arena / collector code.
  • Not required: WSL autoMemoryReclaim. Failures continue with reclaim disabled (and in fact the highest mimalloc failure rate was in that control).
  • Not hardware / Windows host alone. Native Windows stress of a related JSON workload was clean in our earlier probes; the intermittent crashes we care about here are the WSL2 Rust + mimalloc compile matrix above.
  • Not “only under memory pressure near the cap.” One SIGSEGV happened at ~387 MB RSS on a 16 GB cap.

Ask

  1. Is intermittent corruption / SIGSEGV under WSL2 with mimalloc 3.3.2 a known issue (we saw multithreaded 3.3.x reports such as #1287 / #1356, but our CLI is largely single-threaded)?
  2. Is there a recommended build (MI_SECURE, MI_DEBUG, MI_GUARDED) or env (MIMALLOC_SHOW_ERRORS, MIMALLOC_VERBOSE, MIMALLOC_ALLOW_THP=0, etc.) that would turn these into actionable assertions?
  3. Anything specific about WSL2 + networkingMode=mirrored / experimental reclaim that we should avoid when using mimalloc?

We have switched our default builds back to the system allocator for stability. We can provide more logs, a fault-handler build, or try a newer mimalloc tag if useful.

Thanks.

Lingua principale
C
Stelle
13.5k
Fork
1.2k
Merge medio
4g 23h
PR unite (30g)
7

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di microsoft/mimalloc

Tutte le issue di microsoft/mimalloc

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.