Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#1,430 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 5 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
8/100
Tipo de issue
Error
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
c, linux, rust, wasm
Área
operating-systems

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
C
Estrellas
13.4k
Forks
1.2k
Merge medio
4 d 8 h
PR fusionados (30 d)
8

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de microsoft/mimalloc

Todos los issues de microsoft/mimalloc

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.