Repository navigation
Long stack traces in core #31080
Description
Activity
I'm not sure what that would entail.
Also - do you mean for things other than async functions?
I was under the impression that we already do have long stack traces in core (for async functions) with --async-stack-traces
I am obviously a big +1 on anything that makes debugging async code easier :)
Reacted by Cees Timmerman and Benjamin E. Coe@benjamingr I’m talking about any async resources, not just async functions here :) So including nextTicks, timers, etc.
I'm +1 on the idea in general.
Alternatives would be to keep these utilities in userland and/or to just vendor one in but keep developing it outside of core.
I'd be OK with that if the vendored module behaved like any other core module. For example, when we added rimraf support, the userland module didn't really have the same developer experience, mostly around things like option names and error handling.
Reacted by Anna Henningsen and antsmartiansorry for asking a basic question: what is a long stack trace? a simulated chain of stack traces that belong to one logical call unit but were never available together in the thread stack due to the presences of async calls? or is it something else?
@gireeshpunathil Yes, exactly.
Reacted by Gireesh PunathilI guess the confusion comes from that the concept is usually referred to as "async stack trace"? (e.g. the
asyncStackTraceimplemented by our inspector agent whenDebugger.setAsyncCallStackDepthis sent, which is implemented using async hooks). So essentially this means we are going to always do this instead of reserving it for handlingDebugger.setAsyncCallStackDepthin the inspector?Reacted by Gireesh Punathil and Benjamin Gruenbaum@joyeecheung Not always – I’m thinking that this would be enabled through e.g. a command line flag.
@addaleax I see. I would be inclined to maintaining this in core instead of vendoring in one in considering we already have an implementation in Node.js core for the inspector. We could essentially just refactor that code so that it reports to something that can be fetched by e.g. our stack trace preparation callback. (this again brings up the issue about making it play along with user-land
Error.prepareStackTracethough)Reacted by Anna Henningsen(this again brings up the issue about making it play along with user-land
Error.prepareStackTracethough)I, personally, would be consider a solution along the lines of #30984 to be perfect (e.g. adding
callFrame.asyncDepth()), but I’m afraid there’s going to be opposition against that like there is for the other PR.@addaleax @joyeecheung just seeing this. I liked @joyeecheung's suggestion of potentially adding an additional parameter to
prepareStackTrace, which could be used to lookup additional interesting information about the stack frame. I can see why folks were squeamish about simply packing this information on to the stack frame objects that originate in (I believe) V8?Perhaps we could hammer out a little RFC document for this proposal?
@bcoe To clarify I was just suggesting fetching the information in our internal stack trace preparation callback, which calls the user-land
Error.prepareStackTrace. To also expose something to the user-land hook could be a nice-to-have, but it seems complicated so I would not consider that a blocker (first of all, be aware that we currently always respect the user-landError.prepareStackTracefrom the main context so it's easy to mess up across contexts if we are not careful).It also should have an option to return stack trace only for userland code.
Reacted by Benjamin Gruenbaum and Cees TimmermanI think this was partially solved in latests V8 with long stack traces with async functions, I'm going to close this.
What about
process.nextTick, timeouts and so on?
With all the work currently being done around async_hooks and stack trace enhancement through e.g. source maps, I’m wondering whether we should bring official long stack trace support into core.
I’d personally love to see it – I’m certainly biased, but for debugging flaky tests alone it would make things a lot easier to not to have to pull in an external utility for that (or to have to write an ad-hoc one).
Alternatives would be to keep these utilities in userland and/or to just vendor one in but keep developing it outside of core. In particular the latter also seems good to me.
@nodejs/async_hooks @bcoe @AndreasMadsen