Repository navigation
util.getCallSites(): rationale for 200-frame cap and possibility to make it configurable #62910
Closed as not planned
Description
Hi,
I’ve been evaluating util.getCallSites() for use in runtime analysis, and I noticed that the API enforces a limit of 200 frames. I could not find documentation explaining the rationale behind this cap.
The limit is enforced at the Node.js util layer, not by V8 itself.
V8’s stack trace facilities (e.g., Error.stackTraceLimit) do not seem to impose such a low fixed bound.
This raises a few questions:
What is the motivation for the 200-frame cap?
Is it purely a performance safeguard?
Are there known pathological cases that justify this specific bound?
Is the limit intended to be a permanent API constraint, or just a conservative initial choice?
Activity
deokjinkim commentedon Apr 24, 2026
Thanks for raising this.
According to document, allowable range of
frameCountis between 1 and 200.https://nodejs.org/docs/latest/api/util.html#utilgetcallsitesframecount-options
So I think this is intended operation.
According to code, use
kDefaultMaxCallStackSizeToCaptureas reference.node/lib/util.js
Lines 537 to 538 in 9c4ca0a
node/deps/v8/src/inspector/v8-stack-trace-impl.h
Line 54 in 9c4ca0a
@RafaelGSS I think you're author of this code. Can I get your feedback if possible?
Refs: #54380
RafaelGSS commentedon Apr 24, 2026
Yes, this is a default set by V8 as pointed by @deokjinkim. Through the inspector from V8 object you could do:
But this API is not available through
util.getCallSites().DivyanshuX9 commentedon Apr 26, 2026
Hi Everyone , i was looking for contribution in node and thanks for the context @RafaelGSS and @deokjinkim! Since setMaxCallStackSizeToCapture supports values well beyond 200, I'd like to take a stab at exposing that through util.getCallSites().
My plan:
Relax or remove the upper bound of 200 in validateInteger (or tie it to a higher constant)
Call setMaxCallStackSizeToCapture with the user-provided frameCount on the C++/inspector side
Update doc/api/util.md to reflect the new allowable range
Add tests covering values>200
@RafaelGSS would you be open to reviewing a draft PR? Happy to open one for early feedback before polishing.
RafaelGSS commentedon Apr 26, 2026
That would a change on V8 API instead. Unless I'm missing something.
DivyanshuX9 commentedon Apr 26, 2026
ok @RafaelGSS , are you saying that calling setMaxCallStackSizeToCapture would require changes in how Node.js interacts with V8's inspector API (e.g., through the Environment or Inspector bindings in src/), making it a heavier change than just relaxing the validateInteger bound?
If so, would a narrower approach be acceptable as a first step like for example, simply raising the upper bound in validateInteger from 200 to a higher value (like kDefaultMaxCallStackSizeToCapture from V8 or a new Node.js-defined constant), without wiring up setMaxCallStackSizeToCapture at all? That way the API becomes more flexible without touching the V8 layer yet.
Happy to go whichever direction you think is right and i'll try to make things happen better.
RafaelGSS commentedon Apr 26, 2026
If we raise the value from 200 to a higher value, this will still be capped at 200 when reaching the V8 state. That's what I'm saying. The Node.js cap is just reflecting what already exists on V8.
DivyanshuX9 commentedon Apr 27, 2026
So I think we should just clarifying in doc/api/util.md that the 200-frame limit comes from V8's inspector internals, so users understand it's not an arbitrary Node.js restriction? or we can go for a (risky)longterm i.e. setMaxCallStackSizeToCapture a realistic path worth to exploring, or is that too invasive given how the inspector state is managed per-Environment?
if longterm option ain't that feasible I'm good with updating doc
github-actions commentedon Jul 27, 2026
This issue has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.