-
Notifications
You must be signed in to change notification settings - Fork 29.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
process: reduce the number of internal frames in async stack trace #27392
Conversation
Previously, we call the JS land `runNextTicks` implementation immediately from JS land after evaluating the main module or the input, so these synchronous JS call frames would show up in the stack trace of the async errors, which can be confusing. This patch moves those calls into C++ so that more of these internal scheduler implementation details can be hidden and the users can see a cleaner a cleaner async JS stack trace.
at two (*fixtures*async-error.js:17:9) | ||
at async three (*fixtures*async-error.js:20:3) | ||
at async four (*fixtures*async-error.js:24:3) | ||
at async main ([eval]:7:5) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was previously:
Error: test
at one (/Users/joyee/projects/node/test/fixtures/async-error.js:4:9)
at two (/Users/joyee/projects/node/test/fixtures/async-error.js:17:9)
at process.runNextTicks [as _tickCallback] (internal/process/task_queues.js:54:5)
at evalScript (internal/process/execution.js:87:11)
at internal/main/eval_string.js:23:3
at async three (/Users/joyee/projects/node/test/fixtures/async-error.js:20:3)
at async four (/Users/joyee/projects/node/test/fixtures/async-error.js:24:3)
at async main ([eval]:7:5)
Error: test | ||
at one (eval:1:2:9) | ||
at two (eval:1:15:9) | ||
at processTicksAndRejections (internal/process/task_queues.js:*:*) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can't totally eliminate this yet because the tick callback is, in the end, implemented in JavaScript to reduce the overhead of calling into JS. (This patch only moves the initial one-off invocation of the tick callback to C++, all subsequent invocations of the tick callback already come from C++, usually through MakeCallback
).
To hide this eventually we may need an API from V8 to mark the call site as internal. But it is at least better than
Error: test
at one (eval:1:2:9)
at two (eval:1:15:9)
at processTicksAndRejections (internal/process/task_queues.js:88:5)
at process.runNextTicks [as _tickCallback] (internal/process/task_queues.js:58:3)
at evalModule (internal/process/execution.js:54:11)
at internal/main/eval_string.js:21:3
at async three (eval:1:18:3)
at async four (eval:1:22:3)
at async main (eval:1:28:5)`
at two (*fixtures*async-error.js:17:9) | ||
at async three (*fixtures*async-error.js:20:3) | ||
at async four (*fixtures*async-error.js:24:3) | ||
at async main (*message*async_error_microtask_main.js:7:5) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was previously:
Error: test
at one (/Users/joyee/projects/node/test/fixtures/async-error.js:4:9)
at two (/Users/joyee/projects/node/test/fixtures/async-error.js:17:9)
at process.runNextTicks [as _tickCallback] (internal/process/task_queues.js:54:5)
at Function.Module.runMain (internal/modules/cjs/loader.js:828:11)
at internal/main/run_main_module.js:17:11
at async three (/Users/joyee/projects/node/test/fixtures/async-error.js:20:3)
at async four (/Users/joyee/projects/node/test/fixtures/async-error.js:24:3)
at async main (/Users/joyee/projects/node/test/message/async_error_microtask_main.js:7:5)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I guess we might want to try to reduce a couple of our internal frames in general. The current default frames are ten and especially with async stack traces it is important not to exceed those just with internal frames that are not important to the user.
I'm thinking that all internal frames should be hidden by default and optionally exposable via Maybe even re-purpose the |
Fixed the test for windows, it's a bit tricky to get the path right so I just went with concatenating the fixture in the string being eval'ed.
See #11893 - there are a few solutions for this that I can think of.
For improving error stack traces, I would prefer 2, but for inspector debugging I'd prefer 1 (which means you can turn the black boxing on/off any time by simply updating the black box patterns) |
I am definitely against that. We do "hide" the internal frames by marking them grey when inspecting errors since the last version. I also want to expand that to fatal exceptions: #27243. For me the main issue with internal frames is that we have a very limited frame size (ten by default) and that fills up quickly. But hiding the internal frames would not allow to collect more userland frames (the internal ones would still count, even if we filter them). Or at least there's no good solution that I am currently aware of. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very much in favor of this change!
Landed in 757f3f8 |
Previously, we call the JS land `runNextTicks` implementation immediately from JS land after evaluating the main module or the input, so these synchronous JS call frames would show up in the stack trace of the async errors, which can be confusing. This patch moves those calls into C++ so that more of these internal scheduler implementation details can be hidden and the users can see a cleaner a cleaner async JS stack trace. PR-URL: #27392 Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Minwoo Jung <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
Previously, we call the JS land `runNextTicks` implementation immediately from JS land after evaluating the main module or the input, so these synchronous JS call frames would show up in the stack trace of the async errors, which can be confusing. This patch moves those calls into C++ so that more of these internal scheduler implementation details can be hidden and the users can see a cleaner a cleaner async JS stack trace. PR-URL: #27392 Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Minwoo Jung <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
Previously, we call the JS land
runNextTicks
implementationimmediately from JS land after evaluating the main module or the
input, so these synchronous JS call frames would show up in the stack
trace of the async errors, which can be confusing. This patch moves
those calls into C++ so that more of these internal scheduler
implementation details can be hidden and the users can see
a cleaner async JS stack trace.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes