Large argv leaves V8 no stack on macOS: `RangeError` at bootstrap, before the first JS frame

[Abhijeet34]

Version

v24.11.1, V8 13.6.233.10-node.28

Platform

Darwin 25.6.0 Darwin Kernel Version 25.6.0 arm64, Apple M2, ARG_MAX 1048576, ulimit -s 8176 KB

Subsystem

v8

What steps will reproduce the bug?

One line, with an empty environment so the block under test is argv alone:

env -i "$(command -v node)" /dev/null "$(node -e "process.stdout.write('a'.repeat(960000))")"

The script is /dev/null, so nothing user-written runs. node -e '' with the same argument dies
identically, which places the fault in the runtime's startup rather than in any code being loaded.

The threshold is sharp. Bisected on the machine above:

Single argument	Result
958,979 bytes	exit 0
958,980 bytes	RangeError: Maximum call stack size exceeded, exit 7
1,000,000 bytes	RangeError: Maximum call stack size exceeded, exit 7

The crash band runs from there to ARG_MAX, 89,596 bytes wide. Above ARG_MAX the shell refuses
the exec with argument list too long and node never starts, which is a different and correctly
reported failure.

Passing the same block as an environment variable behind a short command line dies identically:
env -i "BLOB=$big" node /dev/null exits 7 with an empty command line.

--stack-size removes it, which is the confirmation that the stack is what ran out:

--stack-size=3072   argv   950000 bytes -> exit 0
--stack-size=3072   argv   960000 bytes -> exit 0
--stack-size=3072   argv  1000000 bytes -> exit 0

The environment cannot carry the flag as a workaround, because node refuses it there:

$ env -i NODE_OPTIONS=--stack-size=3072 node -e 'console.log("ran")'
node: --stack-size= is not allowed in NODE_OPTIONS
exit 9

How often does it reproduce? Is there a required condition?

Every time, on macOS, for any argv plus environment block inside the band. Raising the stack rlimit
does not move the threshold: a 1,000,000-byte argument exits 7 at both ulimit -s 8176 and
ulimit -s 65536, because the geometry is measured from the top of the stack rather than from its
size.

What is the expected behavior?

Either of these would be an improvement on the current outcome, and the first is the one worth
having:

1. The stack limit accounts for the argv and environment block the kernel has already placed at the
   top of the main thread's stack, so a large command line costs the isolate nothing.
2. Failing that, node reports the cause. A block that leaves the isolate with no stack should
   produce a diagnostic naming the command-line size, not a RangeError at
   <anonymous_script>:0.

What do you see instead?

RangeError: Maximum call stack size exceeded
    at <anonymous_script>:0

Exit code 7, before the first line of user JavaScript. A caller sees a stack-overflow error for a
program that never ran.

Additional information

The mechanism, from V8's own source, read on v8/v8 main on 2026-09-09. On macOS the kernel
places argv and the environment at the high end of the main thread's stack, and
pthread_get_stackaddr_np returns that same high address:

src/base/platform/platform-darwin.cc:139

Stack::StackSlot Stack::ObtainCurrentThreadStackStart() {
  return pthread_get_stackaddr_np(pthread_self());
}

The initial JS stack limit is then set that far below the stack start, with no allowance for what
the kernel already wrote there:

src/execution/stack-guard.cc:247

void StackGuard::ThreadLocal::Initialize(Isolate* isolate,
                                         const ExecutionAccess& lock) {
  const uintptr_t kLimitSize = v8_flags.stack_size * KB;
  DCHECK_GT(base::Stack::GetStackStart(), kLimitSize);
  uintptr_t limit = base::Stack::GetStackStart() - kLimitSize;

v8_flags.stack_size defaults to V8_DEFAULT_STACK_SIZE_KB, which is 984 on this target
(src/common/globals.h, the #else branch: "Slightly less than 1MB, since Windows' default stack
size for the main execution thread is 1MB"). 984 KiB is 1,007,616 bytes, and the measured ceiling
is 958,980, so about 47.5 KiB of that budget is gone to node's own bootstrap frames before the
first stack check runs. The rest of the budget is consumed by the argv block sitting above the
stack pointer but below GetStackStart().

The DCHECK_GT on the line above compares the stack start against the limit size in absolute
terms, so it does not catch this: the stack start is a large address and passes the check while the
usable region beneath it is already gone.

Other platforms do not reach the band, for unrelated reasons rather than because they handle it:

• Linux (Debian 12 and Alpine, measured 2026-09-07) refuses any single argument over 131,072 bytes
  with E2BIG at exec, so the per-argument path fails before node starts. The total is larger:
  23 arguments of 90,000 characters, 2,070,023 bytes, answered normally on both images.
• Windows caps a whole command line at 32,767 characters, far below the band.

Prior art

Searched on 2026-09-09 across nodejs/node issues, nodejs/help issues, and the V8 tracker, on
the symptom terms (argv, ARG_MAX, argument list too long, exit status 7, stack base,
anonymous_script) and the mechanism terms. No open or closed report describes this.

The nearest is nodejs/node#28319, "node js script
exits when input is large". It reports the same visible symptom, exit status 7 with the script
never starting, but on Linux at 170,000 bytes, and it was closed in 2019 as a kernel limitation:

It's a kernel limitation and as such not under our control. I'll close this out.

That answer is right for the Linux E2BIG path and does not cover this one. Here the exec
succeeds, node starts, and the process dies inside V8's own bootstrap on a block the kernel
accepted.

The V8 tracker at issues.chromium.org requires sign-in to search, so that half of the search was
done through public web search rather than against the tracker directly. Worth re-running from a
signed-in session before filing.

[abhinav-phi]

I'll dig into this - reproduce locally with the oversized argv to confirm the stack budget at bootstrap, trace where the V8 stack limit is set relative to argv size on macOS, and propose a guard/resize for the main-thread stack in the bootstrap path with a regression test where feasible.

/assign
take

[Renegade334]

Without doing too much investigation, this was likely addressed in V8 by v8/v8@5a54f45.

Unless there is a genuine real-world usage case where a script needs a million characters of command-line arguments, I suggest we close this as informational.