BoaがASANのfake stackでスタック使用量を誤判定した

Thu, 10 Sep 2026 20:14:12 +0900

前回の記事では、Boaのパーサーが2 MiBのスタックを使い切る問題を修正しました。

再帰中のフレームを小さくし、深すぎる入力にはエラーを返すようにしました。通常のビルドでは、元のTest262も2 MiBで通るようになっています。

その状態でAddressSanitizer（ASAN）を使った診断を進めると、今度は浅い入力まで拒否するようになりました。

parser recursion limit exceeded

スタックを使い切らないように追加した保護が、使い切っていないところで止めていました。Issue #640の話です。

同じ実行ファイルなのに設定を変えると通る

最初に確認したのは、Test262のtest/built-ins/Function/prototype/constructorです。

x86_64 Linux、Rust 1.98.1、ASANを有効にしたreleaseビルドで、workerのスタックは8 MiBありました。

同じ実行ファイルとテストを使い、ASANの設定だけを切り替えたところ、結果が変わりました。

`detect_stack_use_after_return`	結果
`1`	0/1。`assert.js`の読み込み時に再帰制限へ到達
`0`	1/1。normalとstrictの両方で成功

比較ログは当時のCI runのartifactにあるcalibration-1.logとcalibration-0.logに残しています。

テスト本体の複雑な処理どころか、テスト用のassert.jsを読み込む段階で止まっています。前回の深い入れ子とは少し様子が違いました。

前回追加したスタック使用量の検査では、解析の入口で小さなローカル変数を作り、そのアドレスを記録していました。

let marker = 0_u8;
cursor.enter_parser(std::ptr::from_ref(&marker) as usize, interner)?;

一番外側の解析で記録したアドレスと、現在の解析で得たアドレスの差を、スタック使用量として扱う方式です。

外側の解析にあるmarkerのアドレス
 ↓ アドレスの差
再帰先の解析にあるmarkerのアドレス

ここには、両方のmarkerが同じnative stack上に置かれているという前提があります。

ASANのfake stackを有効にすると、この前提が崩れました。

ASANには、関数から戻ったあとで、その関数のローカル変数を参照してしまう不具合を検出する機能があります。stack-use-after-returnの検査です。

通常のスタック領域は、関数から戻ると次の呼び出しで再利用されます。そこでASANは検査対象のローカル変数をfake stackという別の領域へ配置し、関数が終わったあとにその領域へのアクセスを検出できるようにします。ASANの設計文書に仕組みが説明されています。

この配置では、ローカル変数のアドレス同士が遠く離れていても、その分だけnative stackを消費したとは限りません。

今回の実装は、その距離をそのまま使用量として扱っていました。浅い解析でも1.5 MiBを超えたと判定され、保護処理がエラーを返していたわけです。

ASANが不正アクセスを報告して止めたのではなく、ASANによって変わった変数配置をパーサー側が読み違えていました。

Boa PR #89では、x86_64とARM64について、CPUのスタックポインタを直接読む方式に変更しました。

x86_64ではrspを読みます。

let address: usize;
unsafe {
 core::arch::asm!(
 "mov {}, rsp",
 out(reg) address,
 options(nomem, nostack, preserves_flags)
 );
}

ARM64ではspを読みます。