Omoikaneのbaseline JITでAcid3がメモリ異常終了する原因を追った

Sun, 13 Sep 2026 20:20:51 +0900

自作ブラウザのOmoikaneでCSSの実装を進めていたところ、Acid3がメモリ異常で落ちるようになりました。

問題が出たのはbaseline JITを有効にした場合だけです。interpreterでは通ります。

さらに、OmoikaneのAcid3 runnerにはFaithfulとDirectDriveという2つの実行方法がありますが、Faithfulは100点まで完了し、そのあとのDirectDriveで落ちていました。

環境によって壊れ方も違います。

環境	発生した異常
x86_64 Linux	SIGSEGV
ARM64 Linux	SIGABRT、約60 GBのallocation、再実行ではSIGSEGV
ARM64 macOS	SIGSEGV、再実行ではSIGBUS

同じテストなのにsignalが揃っていません。

CSSの変更で見つかった問題ですが、結果的にはCSSではなく、Boaのshared shapeが持つ弱参照キャッシュの寿命が原因でした。

Issue #755とPR #757の話です。

FaithfulとDirectDrive

先に、OmoikaneのAcid3 runnerにある2つの実行方法について説明します。

どちらも同じAcid3のページを読み込み、同じ100個のsubtestを実行します。違うのは、Acid3のテストループをどう進めるかです。

Faithfulでは、ページ内のinline event handlerを接続して実際のloadイベントを発火します。

Acid3の<body onload="update()">がOmoikaneのevent処理を通って実行され、その後は仮想時計を進めながら、setTimeout(update, 10)で予約された処理を順番に動かします。

load event
 -> <body onload="update()">
 -> setTimeout(update, 10)
 -> 仮想時計を進める
 -> 次のupdate()

実際のブラウザでページを開いたときに近い経路です。event handlerの接続、timer、callback、event loopのどこかが壊れていれば、途中で進まなくなります。

DirectDriveでは、このsetTimeoutの連鎖を使いません。

runner側からupdate()を直接呼び、subtestを一つずつ進めます。iframeやobjectの読み込みに必要な0msのtaskだけは処理しますが、Acid3自身が予約する10ms timerは迂回します。

runner
 -> update()を直接呼ぶ
 -> 必要な0ms taskを処理
 -> 次のupdate()を直接呼ぶ

これは、timerやload eventの実装が未完成でも、JavaScript engineやDOMが個々のsubtestをどこまで処理できるかを見るための基準です。