Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#1,430 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 5 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
8/100
issue の種類
バグ
明瞭さ
説明が足りない
活発さ
活発
技術スタック
c, linux, rust, wasm
領域
operating-systems

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
C
スター
13.5k
フォーク
1.2k
平均マージ
4日 23時間
マージ済み PR（30日）
7

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

microsoft/mimalloc のほかの issue

microsoft/mimalloc の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。