Allocating TypedArray crashes if MaxStackUsage is configured

[handerss-spotfire]

After upgrading to ClearScript 7.5.1 our test suite has started crashing with the following error (similar error as in #712 (comment)):

Exit code is -2147483645 (#
# Fatal error in , line 0
# Check failed: isolate_->IsOnCentralStack().
#
#
#
#FailureMessage Object: 000000A9947FC0E0)

This happens on every run after a couple of tests have been executed. Each test creates a fresh V8Runtime.

I'll see if I can create a re-producible minimal repro.

[handerss-spotfire]

Only occurs when setting MaxStackUsage. It does not seem to matter which value we set as max however.

[handerss-spotfire]

Minimal repro:

This crashes:

using var runtime = new V8Runtime();
runtime.MaxStackUsage = new UIntPtr(734 * 1024);
using var engine = runtime.CreateScriptEngine();
engine.Execute("new Int8Array(65 * 1024 * 1024);");

Removing the MaxStackUsage avoids the crash:

using var runtime = new V8Runtime();
using var engine = runtime.CreateScriptEngine();
engine.Execute("new Int8Array(65 * 1024 * 1024);");

I thought that typed arrays were allocated on the .NET heap, so in theory the stack size should have no effect here?

[handerss-spotfire]

Investigated a bit with the help of Claude Code and tried to summarize what seems to be the issue below.

The crash is caused by a CHECK(isolate_->IsOnCentralStack()) failure in V8's Heap::CollectGarbage (src/heap/heap.cc).

ClearScript/ClearScriptV8/V8IsolateImpl.cpp

Line 1939 in f43eafc

m_upIsolate->SetStackLimit(reinterpret_cast<uintptr_t>(pStackLimit));

EnterExecutionScope calls v8::Isolate::SetStackLimit to enforce MaxStackUsage, and ExitExecutionScope calls it again with a sentinel value of 8 (defined as s_pMinStackLimit) to effectively remove the limit.

V8 commit c24df23717b ("Respect isolate stack limit in GetCentralStackView") added a set_stack_size(Stack::GetStackStart() - stack_limit) call inside v8::Isolate::SetStackLimit. When ClearScript passes 8 as the limit, this computes stack_size_ = stackTop - 8 ≈ 740 GB, corrupting the isolate's stack_size_ field.

When a subsequent V8 operation triggers GC (e.g., allocating a 65 MB typed array), Heap::CollectGarbage checks IsOnCentralStack(), which computes the central stack lower bound as Stack::GetStackStart() - (stack_size_ + 40KB). With the corrupted ~740 GB stack_size_, this underflows, and the CHECK fails.

A suggested fix can be found here (entirely generated so no copyright): handerss-spotfire@a088e68

[ClearScriptLib]

Thanks for reporting this! We're investigating.

[handerss-spotfire]

Any update on this one? Should we look into setting up internal builds with the proposed fix in case we want to use 7.5.1 in August?

[ClearScriptLib]

Hi @handerss-spotfire,

Sorry about the delay. Claude's analysis points at the right places in the code, but it doesn't make it clear why a large stack_size_ value would be state-breaking. Subtracting a small unsigned value from a larger unsigned value should be safe, but clearly something in recent V8 builds is reacting poorly.

In any case, Claude's suggested fix seems reasonable. Our own fix is similar – we're patching in a ResetStackLimit V8 API and leveraging it in ClearScriptV8. We're hoping to post a new release sometime in August, but it'll be based on a newer V8 version, so if you've done extensive testing with the existing version (14.7), it might make sense for you to do a private build.

Good luck!

[handerss-spotfire]

@ClearScriptLib Thanks for the update, it helps a lot!

[AndrewNowosad]

Another data point on the same failure, from a different trigger: a plain CollectGarbage call is enough, no typed arrays and no threads involved.

using var engine = new V8ScriptEngine();
engine.MaxRuntimeStackUsage = (UIntPtr) (256 * 1024);
engine.Evaluate("1 + 1");
engine.CollectGarbage(true);   // Check failed: isolate_->IsOnCentralStack()

Removing the MaxRuntimeStackUsage line makes it pass. The value does not matter, and neither does the script: with MaxRuntimeStackUsage set, the very first CollectGarbage(true) aborts the process even if nothing has been executed at all.

Observed on .NET 10, Windows x64 and linux-x64 (in mcr.microsoft.com/dotnet/runtime:10.0), with the ClearScript assembly version printed at runtime to be sure of what was loaded:

ClearScript	CollectGarbage(true) without the limit	with the limit
7.4.1	ok	ok
7.5.0	ok	ok
7.5.1	ok	abort

Which lines up with @handerss-spotfire's analysis: the sentinel reset in ExitExecutionScope corrupts stack_size_, and any later GC trips the central-stack CHECK — whether that GC comes from an allocation inside a script or from a host call to CollectGarbage.

This matters for embedders that pool engines: a host that collects garbage periodically will crash sooner or later once a stack budget is configured, so MaxRuntimeStackUsage is effectively unusable on 7.5.1. We just had to withdraw a stack budget feature from our product for that reason.

@ClearScriptLib one question about the plan: you mentioned the upcoming release will be based on a newer V8 than 14.7. Would you consider a 7.5.2 on the current V8 14.7 with just this fix? For hosts that have already validated 14.7 in production, a patch release on the same V8 would be much easier to adopt than a V8 upgrade, and it would avoid private builds. If that is not on the table, knowing it would help us decide whether to do one.

[ClearScriptLib]

Hi @AndrewNowosad,

Another data point on the same failure, from a different trigger: a plain CollectGarbage call is enough, no typed arrays and no threads involved.

Yes, as soon as a script is invoked with stack monitoring enabled, the IsOnCentralStack check starts failing. We already have a fix for this internally.

Would you consider a 7.5.2 on the current V8 14.7 with just this fix?

Probably not with just this fix, as we'll be addressing a few other issues, but yes, we're considering releasing 7.5.2 with V8 14.7. We usually try to stay current but are currently struggling with the rebase of our patchset onto V8 15.x.

[ClearScriptLib]

Hi @AndrewNowosad,

An update: Our plan is to release ClearScript 7.5.1.1 with V8 14.7 very soon. ClearScript 7.5.2 with V8 15.x will follow soon after that.

Cheers!