util.getCallSites(): rationale for 200-frame cap and possibility to make it configurable

[scull06]

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?

[deokjinkim]

Thanks for raising this.
According to document, allowable range of frameCount is 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 kDefaultMaxCallStackSizeToCapture as reference.

node/lib/util.js

Lines 537 to 538 in 9c4ca0a

	// Using kDefaultMaxCallStackSizeToCapture as reference
	validateInteger(frameCount, 'frameCount', 1, 200);

node/deps/v8/src/inspector/v8-stack-trace-impl.h

Line 54 in 9c4ca0a

static constexpr int kDefaultMaxCallStackSizeToCapture = 200;

@RafaelGSS I think you're author of this code. Can I get your feedback if possible?
Refs: #54380

[RafaelGSS]

Yes, this is a default set by V8 as pointed by @deokjinkim. Through the inspector from V8 object you could do:

inspector->debugger()->setMaxCallStackSizeToCapture(this, 200000);

But this API is not available through util.getCallSites().

[DivyanshuX9]

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]

That would a change on V8 API instead. Unless I'm missing something.

[DivyanshuX9]

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]

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]

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]

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.