You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 22, 2023. It is now read-only.
Hello,
I just had an idea that I think of that it might be feasible as soon as we have V8 isolates available in node. It's not easy to do, but I think that it'd make finding errors much easier because you wouldn't even have to fire up a debugger. Also, you'd even get variables from callback parent scopes which you usually can't see in a regular debugger.
If you call node with a special switch, it opens a debug port and spawns a new isolate that connects to it. When an Error gets created in node, a breakpoint inside the Error constructor kicks in. The isolate receives the "breakpoint hit" event and collects some debug data from the stack, e.g. the types of all variables and maybe also util.inspect representations of them, on all levels. Then, it scans all stack frames for callbacks, puts breakpoints into the callbacks and calls them without arguments (maybe live-patching them before to prevent their actual contents from being run? - not sure whether this would work the way I think). On each breakpoint in such a callback, it collects all variable types and such things again. This happens recursively. When all the work is done, you have a pretty clear image of what was going on when the Error object was created. Now the debugger isolate can attach all that data to the Error and let the master isolate continue crashing.
The text was updated successfully, but these errors were encountered:
Notable changes:
* build: Add a --link-module option to configure that can be used to
bundle additional JavaScript modules into a built binary
(Bradley Meck) nodejs#2497
* docs: Merge outstanding doc updates from joyent/node
(James M Snell) nodejs#2378
* http_parser: Significant performance improvement by having
http.Server consume all initial data from its net.Socket and parsing
directly without having to enter JavaScript. Any 'data' listeners on
the net.Socket will result in the data being "unconsumed" into
JavaScript, thereby undoing any performance gains.
(Fedor Indutny) nodejs#2355
* libuv: Upgrade to 1.7.3 (from 1.6.1), see
https://github.com/libuv/libuv/blob/v1.x/ChangeLog for details
(Saúl Ibarra Corretgé) nodejs#2310
* V8: Upgrade to 4.4.63.30 (from 4.4.63.26) (Michaël Zasso) nodejs#2482
Notable changes:
* build: Add a --link-module option to configure that can be used to
bundle additional JavaScript modules into a built binary
(Bradley Meck) nodejs#2497
* docs: Merge outstanding doc updates from joyent/node
(James M Snell) nodejs#2378
* http_parser: Significant performance improvement by having
http.Server consume all initial data from its net.Socket and parsing
directly without having to enter JavaScript. Any 'data' listeners on
the net.Socket will result in the data being "unconsumed" into
JavaScript, thereby undoing any performance gains.
(Fedor Indutny) nodejs#2355
* libuv: Upgrade to 1.7.3 (from 1.6.1), see
https://github.com/libuv/libuv/blob/v1.x/ChangeLog for details
(Saúl Ibarra Corretgé) nodejs#2310
* V8: Upgrade to 4.4.63.30 (from 4.4.63.26) (Michaël Zasso) nodejs#2482
cherry-picked from v3.x @ 1a6e52d
PR-URL: nodejs/node#2653
Reviewed-By: cjihrig - Colin Ihrig <cjihrig@gmail.com>
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hello,
I just had an idea that I think of that it might be feasible as soon as we have V8 isolates available in node. It's not easy to do, but I think that it'd make finding errors much easier because you wouldn't even have to fire up a debugger. Also, you'd even get variables from callback parent scopes which you usually can't see in a regular debugger.
If you call node with a special switch, it opens a debug port and spawns a new isolate that connects to it. When an
Error
gets created in node, a breakpoint inside theError
constructor kicks in. The isolate receives the "breakpoint hit" event and collects some debug data from the stack, e.g. the types of all variables and maybe alsoutil.inspect
representations of them, on all levels. Then, it scans all stack frames for callbacks, puts breakpoints into the callbacks and calls them without arguments (maybe live-patching them before to prevent their actual contents from being run? - not sure whether this would work the way I think). On each breakpoint in such a callback, it collects all variable types and such things again. This happens recursively. When all the work is done, you have a pretty clear image of what was going on when the Error object was created. Now the debugger isolate can attach all that data to theError
and let the master isolate continue crashing.The text was updated successfully, but these errors were encountered: