Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#1,430 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 5 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
8/100
Loại issue
Lỗi
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Sôi nổi
Công nghệ
c, linux, rust, wasm
Lĩnh vực
operating-systems

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
C
Star
13.4k
Fork
1.2k
Merge trung bình
4 ngày 8 giờ
Pull request đã merge (30 ngày)
8

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của microsoft/mimalloc

Tất cả issue của microsoft/mimalloc

Issue tương tự

Thêm issue về C

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.