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

macOS arm64: std::mem::alloc fails in optimized builds (arm64 syscall wrappers do not declare x1 as clobbered)

クローズ 初心者向け
  • 何か問題がありますか？
#933 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

関連するプルリクエストがすでにマージされています。

  • #958 @LunaStev による — マージ済み

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
78/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
rust
領域
operating-systems

調査の方向性

std/sys/macos/arm64/syscall.waveから始め、issueで挙げられているstd/sys/macos/amd64/syscall.waveのsyscallラッパーと比較します。syscall0からsyscall6でx1を出力として宣言し、次に、提供された割り当て再現コードを使って、-O1以上で最適化したmacOS arm64ビルドを検証します。状態を破損させずに割り当てが成功すれば完了です。issueでは、後で監査する可能性のある他のDarwin arm64ラッパーも示されています。

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

説明

On macOS arm64, std::mem::alloc fails (returns null) or corrupts state in optimized builds (-O1 and up), because the arm64 syscall wrappers do not declare that XNU overwrites x1 with the secondary return value. The x86_64 wrappers already handle the same thing for rdx (see the comment in std/sys/macos/amd64/syscall.wave).

Repro

import("std::mem::alloc")::{mem_alloc, mem_free};
extern(c, "clock") fun c_clock() -> i64;

fun main() -> i32 {
    // A size only known at run time, used for three allocations in a row.
    var n: i64 = 1520 + (c_clock() % 2);
    var a: ptr<u8> = mem_alloc(n * 8);
    var b: ptr<u8> = mem_alloc(n * 8);
    var c: ptr<u8> = mem_alloc((n + 1) * 8);
    if (a == null || b == null || c == null) {
        println("out of memory for {} entries", n);
        return 1;
    }
    println("ok {}", n);
    mem_free(a, n * 8);
    mem_free(b, n * 8);
    mem_free(c, (n + 1) * 8);
    return 0;
}

Result on a GitHub macos-26 (Apple Silicon) runner, wavec 0.2.1-pre-beta, aarch64-apple-darwin release:

flags result
-O0 ok 1520
-O1, -O2, -O3 out of memory for 1520 entries (exit 1)

I did not run this exact program elsewhere, but the larger programs below build with -O2 and pass on macos-26-intel (x86_64), Linux x64 and Linux arm64. In those larger programs (the examples of https://github.com/potatosl/wjson) the same bug showed up as null from mem_alloc in a CSV example at -O1 and above, and as a segmentation fault (exit 139) in a JSON editing example at -O2 and above. All of them pass at -O0.

Cause (my reading, confirmed by the fix below)

std/sys/macos/arm64/syscall.wave declares the inputs x16, x0..x5 and the output x0, and nothing else. XNU's arm64 syscall return writes x1 as well. With inlining, the compiler assumes x1 still holds the second argument (here the mmap length) after the svc, reuses that value for the next call, and the next mmap gets length 0 or garbage and fails. std/sys/macos/amd64/syscall.wave has this comment for rdx and declares out("rdx") secondary in every wrapper.

Fix

Declare x1 as an output in every arm64 wrapper (syscall0 .. syscall6):

pub fun syscall2(id: i64, a1: i64, a2: i64) -> i64 {
    var ret: i64;
    var secondary: i64;
    asm {
        "svc #0x80\ncneg x0, x0, cs"
        in("x16") id
        in("x0") a1
        in("x1") a2
        out("x0") ret
        out("x1") secondary
    }
    return ret;
}

Verified on the same runner by patching all 7 wrappers in a copy of std and passing it with --std-root:

flags result
-O1, -O2, -O3 ok 1520 / ok 1521, exit 0

The two larger examples (edit_config: segfault, csv2json: out of memory at -O1/-O2/-O3 with the stock std) also pass at -O2 and -O3 with the patched std.

Other wrappers that use the same raw-syscall pattern on Darwin arm64 (fs.wave, process.wave, time.wave, ...) may have the same gap; I only checked memory. Related audit: #434.

主要言語
Rust
スター
56
フォーク
21
平均マージ
4時間 58分
マージ済み PR（30日）
54

環境構築

はじめの一歩

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

wavefnd/Wave のほかの issue

wavefnd/Wave の issue をすべて見る

似ている issue

Rust の issue をもっと見る

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

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