Boa

BoaでPromiseを保持し忘れてmallocが壊れた

Thu, 10 Sep 2026 20:37:07 +0900

BoaのTest262を回していたら、たまにテストが終了コード134で落ちました。

ログには、こんなエラーが出ています。

malloc(): unsorted double linked list corrupted

Issueは通常Test262のrelease実行がallocator整合性エラーで中断するです。

最初は、最近入った変更のどこかでメモリを壊しているのだろうと思いました。ただ、Test262は並列に大量のテストを実行するので、ログだけではどのテストが原因なのか分かりません。

まずは変更前後を比べる

最初にやったのは、変更前と変更後の比較です。

Boaの変更前revisionと、問題が見つかったrevisionをそれぞれreleaseビルドして、同じ条件でTest262を実行しました。

Ubuntu x86_64
release build
2 MiB worker stack
4 workers

この条件では、変更前後ともに50,595ケースを最後まで実行できました。

47,606 passed
2,056 ignored
933 failed
0 panic

allocatorの異常終了も再現しませんでした。

実行ファイルのSHA256も一致していたので、少なくともこの実行結果からは、別の変更によって壊れたとは言えません。

ただ、問題のCIでは2回続けて終了134になっています。再実行が通ったからといって、問題が解決したとは扱えません。

小さいケースに絞る

ログを見ていると、落ちる直前には次のようなsuiteが実行されていました。

GeneratorFunction/prototype
classのasync private method

どちらもPromiseやasync処理に関係しています。

そこで、全Test262を何度も回すのではなく、Promiseの解決処理でGCが動く条件を小さいテストにしました。

問題になったのは、Promiseの解決中にresolveやrejectを取り出し、そのあとでthen getterを呼ぶような処理です。getterの実行中には、ユーザーコードが動く可能性があります。そこではGCも発生します。

Promiseへの参照が消えていた

Promiseの処理では、内部の共有captureからresolveやrejectを取り出します。

このとき、Promiseを追跡可能な参照として保持している場所まで一緒に失われていました。

通常はすぐに問題が起きません。処理が短く、GCも動かなければ、たまたまメモリ上に残った状態で処理が進むからです。

しかし、そのあとにthen getterやhost hookを呼び出すと、ユーザーコードが実行されます。その間にGCが走ると、Promiseが不要なオブジェクトだと判断され、回収される可能性があります。

その状態で後続処理がPromiseを使おうとすると、解放された領域を参照することになります。

最終的に見えていたのが、allocatorの内部データ構造が壊れたというエラーでした。

malloc(): unsorted double linked list corrupted

エラーがmallocから出ているので、最初はヒープのどこかを直接壊しているように見えます。実際には、GCによる回収と参照の保持が正しく対応していないことが入口でした。

回帰テストで再現する

修正前のrevisionに回帰テストだけを追加して実行すると、ARM64 LinuxでSIGSEGVを再現できました。

このテストは、次のような条件を含めています。

then getterがcallableを返す
then getterがcallableではない値を返す
then getterが例外を投げる
Promise解決中に再入してresolveやrejectを呼ぶ

単純にPromiseが解決するだけなら問題が出ないので、getterの呼び出しとGCが入り得る箇所を組み合わせる必要がありました。

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を有効にすると、この前提が崩れました。

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を読みます。

Boaのパーサーが2 MiBのスタックを使い切った

Thu, 10 Sep 2026 19:58:13 +0900

OmoikaneへBoaを取り込む前にTest262を動かしていたところ、未最適化のパーサーがstack overflowでabortするケースが見つかりました。

失敗したのはTest262のregress-672893.jsです。

無効なJavaScriptを何万段も入れ子にしたわけではありません。関数式を15段ほど入れ子にした有効なJavaScriptでした。

構造を省略すると、次のようなコードです。

function f() {
 return function () {
 return function () {
 ...同じ形で15段まで続く...
 return function (a) {
 var v = a;
 return function () { return v; };
 };
 };
 };
}

f()()() ... ()(42)();

このコードをdev profileでビルドしたBoaへ渡し、スレッドスタックを2 MiBにすると、パーサーがstack overflowを起こしてexit 134で終了しました。

同じコードでも8 MiBなら通ります。また、JITやJavaScriptの実行中ではなく、ソースコードをASTへ変換する途中で落ちていました。

入れ子1段で約125 KB使っていた

デバッガで関数式の解析フレーム間を測ると、修正前の未最適化aarch64 Linuxでは、入れ子1段あたり125,360 bytes使っていました。

15段なら単純計算で約1.88 MBです。これにパーサー以外の呼び出し、lexer、エラー処理なども加わるため、2 MiBのスタックには収まりません。

原因は、再帰的な式解析が後半の処理で使うASTの一時値を保持したまま、次の関数本体を解析していたことでした。

例えば二項演算子を処理するパーサーでは、まず左辺を解析し、そのあとに続く演算子と右辺を処理します。

左辺を解析する
 ↓
演算子が続いているか調べる
 ↓
右辺を解析してASTを組み立てる

関数全体が一つになっていると、後半で使う変数やASTのための領域まで含んだ大きいフレームを作り、その状態で左辺の解析へ入ります。