Boa

After implementing Omoikane’s DOM and exception notifications, we ended up investigating copying and garbage‑collection lifetimes as well.

Sat, 10 Oct 2026 17:42:29 +0900

We added DOM operations such as before() and replaceChildren() to Omoikane, along with window.onerror and notifications for unhandled Promise rejections. [PR #1322](https://github.com/ieee0824/omoikane/pull/1322) This is about that pull request. The initial issue was straightforward: the page lacked the APIs it normally calls. However, as we progressed with implementation and testing, we ended up fixing issues such as copying sibling lists when inserting HTML text, rebuilding the entire document after UTF‑16 appends, creating unnecessary iframe realms, and even addressing insufficient GC roots for Promises.

WeakMap and Generational Garbage Collection

Thu, 08 Oct 2026 21:52:45 +0900

Opening https://tokyo6.tokyo/ with Omoikane caused a bug where the script terminated with a SIGSEGV during execution. Issue #1223 (issue #1223) reproduces the problem not only in the GUI but also in the screenshot feature that renders the screen to an image. The backtrace from the debug build reproduced on a Linux aarch64 Docker development environment with Xvfb showed that Boa’s garbage collector halted while traversing references to an object.

The fix in PR #1260 (PR #1260) addressed the combination of an ephemeron—a conditional reference—and the generational garbage collector. A young object that was referenced by an older object was being reclaimed during the minor GC that followed a major GC. Subsequently, the major GC followed a reference that had already been freed, causing a crash.

The object returned by Boa’s getter was collected by the garbage collector while the inline cache was being updated.

Wed, 30 Sep 2026 08:12:00 +0900

When running the test for a custom element associated with a form in Omoikane’s Web Platform Tests (WPT), it caused a SIGSEGV. The first occurrence was in a configuration that included the JIT, so we initially suspected an interaction between Boa’s JIT or its garbage collector. However, even when the JIT was disabled, the same crash could be reproduced (issue #858), and ultimately the problem lay in a tiny interval between when the getter’s returned object was produced and when it was stored in the VM’s registers.

Since generating realms with Omoikane was slow, I looked into Boa’s scope lookup and lexical analysis.

Tue, 29 Sep 2026 18:25:00 +0900

In the blog post investigating Omoikane’s CI wait times, we wrote about avoiding heavy verification for changes that only affect documentation and about revisiting the build cache. Separate from that, the tests that actually needed to be run were also taking a considerable amount of time. (source)

Omoikane uses Boa to execute JavaScript. Each time a JavaScript realm is created for a page or an iframe, a large script that sets up the DOM API is run. This processing accounted for a substantial portion of the test runtime. In Issue #1154, instead of reducing the number of tests or realms, we investigated this initialization itself.

A SIGSEGV occurred after garbage collection because the iterator function passed to Boa’s Array.from was not properly retained.

Fri, 25 Sep 2026 08:46:00 +0900

While running Omoikane’s Acid3 test, the process hit a SIGSEGV under the baseline JIT configuration on macOS ARM64. I briefly mentioned this in the earlier blog post about Omoikane updates, but the cause wasn’t the test itself nor the JIT’s machine‑code generation; it lay in the Boa code we’re incorporating, specifically in the Array.from() section. Omoikane incorporates Boa’s source code together with the browser‑side implementation, so the fix was also applied to the engine that pulls in that code. (source)

I investigated why Acid3 was crashing due to memory errors in Omoikane’s baseline JIT.

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

While working on implementing CSS in my own browser, Omoikane (source), Acid3 began crashing due to memory errors.

The problem only occurs when the baseline JIT is enabled; it runs fine with the interpreter.

Furthermore, Omoikane’s Acid3 runner has two execution modes, Faithful and DirectDrive. Faithful completes all 100 points, but then it crashes during DirectDrive.

The failure manifests differently depending on the environment.

Environment	Observed failure
x86_64 Linux	SIGSEGV
ARM64 Linux	SIGABRT, ~60 GB allocation, SIGSEGV on rerun
ARM64 macOS	SIGSEGV, SIGBUS on rerun

Even though it’s the same test, the signals differ.

I forgot to keep a Promise alive in Boa, which broke the malloc.

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

While running Boa’s Test262, the test occasionally failed with exit code 134.

The logs show the following errors:

malloc(): unsorted double linked list corrupted

The issue is the “normal Test262 release run is aborted due to an allocator consistency error” (issue #638).

At first, I assumed some recent change was corrupting memory somewhere. However, because Test262 runs a large number of tests in parallel, the logs alone don’t reveal which specific test is causing the problem.

Boa incorrectly judged stack usage due to ASAN's fake stack.

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

In the previous article, we fixed the issue where Boa’s parser exhausted a 2 MiB stack. (related article)

We reduced the frame size during recursion and made it return an error for inputs that are too deep. With a normal build, the original Test262 now also passes within the 2 MiB limit.

When we continued diagnosing with AddressSanitizer (ASAN) in that state, it started rejecting even shallow inputs.

parser recursion limit exceeded

The protection we added to prevent stack exhaustion was stopping prematurely, even though the stack hadn’t been fully used. This concerns Issue #640.

Boa's parser exhausted a 2 MiB stack

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

While running Test262 before importing Boa into Omoikane, we discovered a case where an unoptimized parser aborts due to a stack overflow (issue #633).

The failure occurred in Test262’s regress-672893.js.

It wasn’t a matter of nesting tens of thousands of invalid JavaScript statements. It was valid JavaScript with about fifteen levels of nested function expressions.

If we omit the structural details, the code looks like this:

function f() {
 return function () {
 return function () {
 ...continues in the same pattern up to 15 steps...
 return function (a) {
 var v = a;
 return function () { return v; };
 };
 };
 };
}

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

When this code is passed to a Boa built with the dev profile and the thread stack is set to 2 MiB, the parser triggers a stack overflow and exits with status 134.

Boa