util: recover from maximum call stack size #20725

BridgeAR · 2018-05-14T19:35:27Z

Using util.inspect should still return values in case the maximum
call stack size is reached. This is important to inspect linked
lists and similar.

Checklist

make -j4 test (UNIX), or vcbuild test (Windows) passes
tests and/or benchmarks are included
documentation is changed or added
commit message follows commit guidelines

BridgeAR · 2018-05-14T19:35:58Z

CI https://ci.nodejs.org/job/node-test-pull-request/14869/

addaleax

LGTM if it doesn’t affect the benchmarks negatively

apapirovski

LGTM

mscdex

I think at the very least this should be a separate option for util.inspect(). I would not expect to get back something I did not request. It should be all or nothing (meaning either the stack overflow error should occur or an error be thrown -- something to indicate the request could not be completed as asked).

If the user wants to explicitly opt-in to this behavior, that's fine because then they know what they could be getting into at that point.

addaleax · 2018-05-14T21:29:27Z

Here’s a benchmark CI: https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/191/

But yes, I’m generally +1 on this PR. I don’t see the point of emitting a stack overflow error if we can avoid it at little cost. I don’t think setting depths to these high values makes sense in real-world applications anyway, but if somebody does that, then util.inspect() should yield some sensible output.

BridgeAR · 2018-05-16T15:29:11Z

Seems like TypedArrays take a minor hit of up to 4%. The other entries seem to be sough (I reran the benchmarks). I am going to play around with it to see if I am able to get that further down. I am a bit surprised that it has impact on those but not on e.g. nested objects.

About having depth levels like these in real world applications: This should indeed be highly unlikely as the output would mainly just be whitespace. I can not imagine that anyone would look at this and I can also not think of a use case where this would be useful programmatically. It would just not be useful anymore.

TimothyGu · 2018-05-20T15:53:12Z

Seems like TypedArrays take a minor hit of up to 4%.

I don't believe this should be a factor in deciding whether the PR should land. Agreed with @addaleax on user experience vs. cost.

BridgeAR · 2018-05-21T20:32:16Z

I had another look at this and found a solution that does not show the regression.

~~CI https://ci.nodejs.org/job/node-test-pull-request/15004/~~
CI https://ci.nodejs.org/job/node-test-pull-request/15006/

BridgeAR · 2018-05-21T21:12:18Z

Benchmark: https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/199/

BridgeAR · 2018-05-23T15:05:58Z

The benchmarks clearly show no regression (it will only effect very deeply nested objects - if at all).

I believe the user experience is better by returning a value instead of throwing. Inspecting any deeper will not provide a result that would still be really useful.

@mscdex are you strongly -1 on this?

mcollina

LGTM. I think this will help new users.

joyeecheung · 2018-05-26T14:27:30Z

I am -0.5 on this. In real-world applications that I've seen issues like this, even if the stack overflow doesn't happen, the process may run out of memory because of the complexity of the object. String concatenation in V8 is memory-expensive (each + takes up 24 bytes the last time I checked), not to mention all the whitespaces could result in a really large string which lives on the V8 heap, so this could trigger hard crashes instead of exceptions in those cases, and it could be much harder for users to understand what caused those crashes without post-mortem debugging.

BridgeAR · 2018-05-26T14:32:42Z

@joyeecheung the max stack size with be exceeded much much before the heap memory is. When I ran a different implementation that was recovering from the max stack size I was able to inspect a depth of almost 100.000. This will end inspection at a depth of ~1500 for the very simple case and earlier for more complex cases.

joyeecheung · 2018-05-26T14:41:04Z

@joyeecheung the max stack size with be exceeded much much before the heap memory is. When I ran a different implementation that was recovering from the max stack size I was able to inspect a depth of almost 100.000. This will end inspection at a depth of ~1500 for the very simple case and earlier for more complex cases.

IIUC, this ends the inspection early in the sense that it will return the formatted subtree to be concatenated later, it does not mean that the whole inspection process will end once the formatter finds one deep subtree in the object, so more memory will be consumed if the object is not skewed (containing multiple deep subtrees).

BridgeAR · 2018-05-26T14:48:25Z

@joyeecheung that is correct but a very unlikely case. To have a object like this will likely cause problems one way or the other. The problem you speak about should be solved with #19994.

ofrobots

I'm +1 on this as this is a debugging tool. Returning something is better than the stack-overflow.

mhdawson

LGTM

Trott · 2018-05-28T20:53:49Z

Just in case we start getting into vote-counting territory for the TSC (since it does seem unlikely that the impasse here will be resolved):

I'm an abstention. I defer to people who encounter these kinds of issues in real world applications more frequently than I do.

Trott · 2018-05-28T20:55:39Z

(UPDATE: I'll be updating the preliminary vote counts as TSC people weigh in.)

Since this is at an impasse that seems unlikely to be resolved, I think calling for a vote at this time is appropriate. The way things stand now, as I see it at least:

7 TSC in favor (@addaleax @danbev @mcollina @mhdawson @ofrobots @thefourtheye @TimothyGu)
1 TSC opposed (or opposed-ish) (@joyeecheung)
1 TSC abstention (@Trott)

There are 18 TSC members total, so this will require participation by at least another 2 TSC members to achieve a resolution.

@nodejs/tsc

joyeecheung · 2018-05-29T11:46:38Z

@BridgeAR Have you considered @mscdex 's suggestion about making the recovery opt-in?

BridgeAR · 2018-05-29T18:43:50Z

@joyeecheung I did consider it but we already have a lot of options for util.inspect and if it does not provide a substantial benefit I do not think we should add more. This PR should fix a rare edge case and makes sure the result will be somewhat usable. If it comes down to adding a new option or to add this change, I would rather close the PR again.

Fishrock123

This seems like reasonable behavior to me

joyeecheung · 2018-06-06T17:45:36Z

I am not +1 but I would not block this. We can see how the users react to this in the wild and revert if necessary.

targos

LGTM but I would like Anna's suggestion to be implemented before landing

Trott · 2018-06-06T17:49:16Z

To break the impasse, we had a vote in the TSC meeting today. This PR can land (assuming green CI).

Vote results:

Yes (9): @mcollina @jasnell @targos @danbev @addaleax @mhdawson @Fishrock123 @thefourtheye @ofrobots
No (0):
Abstain (5): @ChALkeR @cjihrig @Trott @rvagg @fhinkel

Votes add up to 14 rather than 18 because 4 members were not involved in the vote:

@TimothyGu was not at the meeting to vote but is favorable to this PR above.
@joyeecheung did not vote that I saw in the meeting and may have dropped off by the time the vote happened. She was generally not favorable above, at least as I interpreted it, but not strongly so.
@MylesBorins was not at the meeting and has not commented on this issue as far as I can tell.
@gibfahn was not at the meeting and has not commented on this issue as far as I can tell.

I'll remove the tsc-agenda label.

Using util.inspect should still return values in case the maximum call stack size is reached. This is important to inspect linked lists and similar.

BridgeAR · 2018-06-11T01:06:32Z

I just pushed the requested change @addaleax

BridgeAR · 2018-06-11T01:59:02Z

CI https://ci.nodejs.org/job/node-test-pull-request/15380/

Dimissing the review due to the TSC vote.

Trott · 2018-06-11T03:29:32Z

CI again: https://ci.nodejs.org/job/node-test-pull-request/15382/

targos · 2018-06-24T13:26:38Z

CI again 2: https://ci.nodejs.org/job/node-test-pull-request/15577/ ✔️

apapirovski · 2018-06-25T06:12:22Z

Landed in b26506b

Using util.inspect should still return values in case the maximum call stack size is reached. This is important to inspect linked lists and similar. PR-URL: #20725 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Anatoli Papirovski <apapirovski@mac.com> Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com> Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>

Notable changes: * build: * Node.js should now be about 60% faster to startup than the previous version, thanks to the use V8's code cache feature for core modules. [#21405](#21405) * dns: * An experimental promisified version of the dns module is now available. Give it a try with `require('dns').promises`. [#21264](#21264) * fs: * `fs.lchown` has been undeprecated now that libuv supports it. [#21498](#21498) * lib: * `Atomics.wake` is being renamed to `Atomics.notify` in the ECMAScript specification ([reference](tc39/ecma262#1220)). Since Node.js now has experimental support for worker threads, we are being proactive and added a `notify` alias, while emitting a warning if `wake` is used. [#21413](#21413) [#21518](#21518) * n-api: * Add API for asynchronous functions. [#17887](#17887) * util: * `util.inspect` is now able to return a result instead of throwing when the maximum call stack size is exceeded during inspection. [#20725](#20725) * vm: * Add `script.createCachedData()`. This API replaces the `produceCachedData` option of the `Script` constructor that is now deprecated. [#20300](#20300) * worker: * Support for relative paths has been added to the `Worker` constructor. Paths are interpreted relative to the current working directory. [#21407](#21407) PR-URL: #21629

Notable changes: * dns: * An experimental promisified version of the dns module is now available. Give it a try with `require('dns').promises`. [#21264](#21264) * fs: * `fs.lchown` has been undeprecated now that libuv supports it. [#21498](#21498) * lib: * `Atomics.wake` is being renamed to `Atomics.notify` in the ECMAScript specification ([reference](tc39/ecma262#1220)). Since Node.js now has experimental support for worker threads, we are being proactive and added a `notify` alias, while emitting a warning if `wake` is used. [#21413](#21413) [#21518](#21518) * n-api: * Add API for asynchronous functions. [#17887](#17887) * util: * `util.inspect` is now able to return a result instead of throwing when the maximum call stack size is exceeded during inspection. [#20725](#20725) * vm: * Add `script.createCachedData()`. This API replaces the `produceCachedData` option of the `Script` constructor that is now deprecated. [#20300](#20300) * worker: * Support for relative paths has been added to the `Worker` constructor. Paths are interpreted relative to the current working directory. [#21407](#21407) PR-URL: #21629

BridgeAR added the semver-minor PRs that contain new features and should be released in the next minor version. label May 14, 2018

nodejs-github-bot added the util Issues and PRs related to the built-in util module. label May 14, 2018

addaleax approved these changes May 14, 2018

View reviewed changes

apapirovski approved these changes May 14, 2018

View reviewed changes

TimothyGu approved these changes May 14, 2018

View reviewed changes

mscdex previously requested changes May 14, 2018

View reviewed changes

BridgeAR force-pushed the safe-linked-list branch from a743cbc to 630360c Compare May 21, 2018 21:00

BridgeAR added tsc-review tsc-agenda Issues and PRs to discuss during the meetings of the TSC. labels May 24, 2018

BridgeAR requested a review from a team May 24, 2018 16:38

mcollina approved these changes May 24, 2018

View reviewed changes

BridgeAR requested a review from a team May 25, 2018 10:23

ofrobots approved these changes May 27, 2018

View reviewed changes

BridgeAR requested a review from a team May 27, 2018 22:04

mhdawson mentioned this pull request May 28, 2018

Node.js Foundation Technical Steering Committee (TSC) Meeting 2018-05-30 nodejs/TSC#547

Closed

mhdawson approved these changes May 28, 2018

View reviewed changes

BridgeAR requested a review from a team May 28, 2018 14:44

mhdawson mentioned this pull request Jun 4, 2018

Node.js Foundation Technical Steering Committee (TSC) Meeting 2018-06-06 nodejs/TSC#549

Closed

thefourtheye approved these changes Jun 5, 2018

View reviewed changes

Fishrock123 approved these changes Jun 6, 2018

View reviewed changes

targos approved these changes Jun 6, 2018

View reviewed changes

Trott removed tsc-agenda Issues and PRs to discuss during the meetings of the TSC. tsc-review labels Jun 6, 2018

BridgeAR added 2 commits June 11, 2018 02:58

util: recover from maximum call stack size

ef4e8d3

Using util.inspect should still return values in case the maximum call stack size is reached. This is important to inspect linked lists and similar.

fixup: add requested change

7748619

BridgeAR force-pushed the safe-linked-list branch from 8214e97 to 7748619 Compare June 11, 2018 01:05

jasnell approved these changes Jun 11, 2018

View reviewed changes

BridgeAR added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Jun 11, 2018

apapirovski closed this Jun 25, 2018

targos mentioned this pull request Jul 3, 2018

v10.6.0 proposal #21629

Merged

BridgeAR deleted the safe-linked-list branch January 20, 2020 11:34

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

util: recover from maximum call stack size #20725

util: recover from maximum call stack size #20725

BridgeAR commented May 14, 2018

BridgeAR commented May 14, 2018

addaleax left a comment

apapirovski left a comment

mscdex left a comment

addaleax commented May 14, 2018

BridgeAR commented May 16, 2018

TimothyGu commented May 20, 2018

BridgeAR commented May 21, 2018 •

edited

Loading

BridgeAR commented May 21, 2018

BridgeAR commented May 23, 2018

mcollina left a comment

joyeecheung commented May 26, 2018 •

edited

Loading

BridgeAR commented May 26, 2018

joyeecheung commented May 26, 2018

BridgeAR commented May 26, 2018

ofrobots left a comment

mhdawson left a comment

Trott commented May 28, 2018

Trott commented May 28, 2018 •

edited

Loading

joyeecheung commented May 29, 2018

BridgeAR commented May 29, 2018

Fishrock123 left a comment

joyeecheung commented Jun 6, 2018 •

edited

Loading

targos left a comment

Trott commented Jun 6, 2018 •

edited

Loading

BridgeAR commented Jun 11, 2018

BridgeAR commented Jun 11, 2018

Trott commented Jun 11, 2018

targos commented Jun 24, 2018 •

edited by BridgeAR

Loading

apapirovski commented Jun 25, 2018

util: recover from maximum call stack size #20725

util: recover from maximum call stack size #20725

Conversation

BridgeAR commented May 14, 2018

Checklist

BridgeAR commented May 14, 2018

addaleax left a comment

Choose a reason for hiding this comment

apapirovski left a comment

Choose a reason for hiding this comment

mscdex left a comment

Choose a reason for hiding this comment

addaleax commented May 14, 2018

BridgeAR commented May 16, 2018

TimothyGu commented May 20, 2018

BridgeAR commented May 21, 2018 • edited Loading

BridgeAR commented May 21, 2018

BridgeAR commented May 23, 2018

mcollina left a comment

Choose a reason for hiding this comment

joyeecheung commented May 26, 2018 • edited Loading

BridgeAR commented May 26, 2018

joyeecheung commented May 26, 2018

BridgeAR commented May 26, 2018

ofrobots left a comment

Choose a reason for hiding this comment

mhdawson left a comment

Choose a reason for hiding this comment

Trott commented May 28, 2018

Trott commented May 28, 2018 • edited Loading

joyeecheung commented May 29, 2018

BridgeAR commented May 29, 2018

Fishrock123 left a comment

Choose a reason for hiding this comment

joyeecheung commented Jun 6, 2018 • edited Loading

targos left a comment

Choose a reason for hiding this comment

Trott commented Jun 6, 2018 • edited Loading

BridgeAR commented Jun 11, 2018

BridgeAR commented Jun 11, 2018

Trott commented Jun 11, 2018

targos commented Jun 24, 2018 • edited by BridgeAR Loading

apapirovski commented Jun 25, 2018

BridgeAR commented May 21, 2018 •

edited

Loading

joyeecheung commented May 26, 2018 •

edited

Loading

Trott commented May 28, 2018 •

edited

Loading

joyeecheung commented Jun 6, 2018 •

edited

Loading

Trott commented Jun 6, 2018 •

edited

Loading

targos commented Jun 24, 2018 •

edited by BridgeAR

Loading