questions for the V8 team

[refack]

I wanted to ask the @v8 and @nodejs/v8 people couple few questions:

1. source map callback (Consider minifying JS sources? node#12471, Support for source maps node#6471) can we have a "source map" resolution callback on creation of a stack trace?
2. Promise and post-mortem (promises and post-mortem debugging post-mortem#16) is there a way to help the post-mortem scenario in V8. Something like hanging the call-stack on the promise chain just for the case of an unhandled rejection?

Thank you.

/cc @nodejs/post-mortem @nodejs/diagnostics

[jeisinger]

could you clarify what you mean by code map? From the referenced issues, I guess you mean source maps?

In general, we don't expose the source map to Javascript, but only use it over the inspector protocol. The inspector, however, should already use the source map when available for all stacks. Some for tracking the async stacks on promises.

[refack]

So in both cases the issue at hand is error handling, either stack traces or post-mortem.

could you clarify what you mean by code map? From the referenced issues, I guess you mean source maps?

Yes, source-maps of course 🤦
The use case is stack-traces: In nodejs/node#12471 @hashseed suggested exposing a callback that will be triggered when a stack trace is created, so we (the embedder) can lookup the a source-map if needed.

Some for tracking the async stacks on promises.

For promises the use-case is post-mortem: even when we trigger a core-dump after an unhandled promise rejection, most of the interesting stacks have already unwound. In nodejs/post-mortem#16 there is a discussion on how to overcome this, but IMHO the most natural solution would be for the VM to give us the tools to create a more helpfull core-dump.

[benjamingr]

@refack I think this is a good initiative - but if we want V8 folk to take a look at all these we should probably ask questions that are a lot less abstract.

[benjamingr]

Also, I think perhaps scheduling a hangout with @nodejs/v8 about the post-mortem case could be beneficial regardless.

[benjamingr]

If I can add - Is it possible to take a copy-on-write core dump with V8? If so, how fast is it?

[bmeck]

@benjamingr thats more an OS question

[refack]

are a lot less abstract.

Ok, I'll write specific use cases...

[hashseed]

re 2). V8's debugger already goes great lengths to predict at reject or throw site whether an unhandled promise rejection will occur, while the stack is still available. This has some false positives though since the prediction cannot be perfect.

[refack]

re 2). V8's debugger already goes great lengths to predict at reject or throw site whether an unhandled promise rejection will occur, while the stack is still available. This has some false positives though since the prediction cannot be perfect.

Thank you for the answer @hashseed !
False positives are not so bad (for post-mortem). Do you know at which version this entered?

[hashseed]

Async/await had this from the start. You need to enable the debugger and enable break on uncaught exception to trigger debug break events.

[refack]

Async/await had this from the start. You need to enable the debugger and enable break on uncaught exception to trigger debug break events.

👍 That is way nodejs/post-mortem promote aysnc/await over promises.
In this case I was referring to a post-mortem core dump. If the stacks are still there when node crashes we should be able to post-mortem the Promise chain.

[benjamingr]

Is there any way to get the async stack (not trace) of a function in V8 without attaching a debugger?

[bmeck]

@refack kind of, try/catch is static and can't be bound late so await has different timing from that perspective; therefore, knowing if it is unhandled is a sync operation.

[Trott]

This issue has been inactive for a while and this repository is now obsolete. I'm going to close this, but feel free to open another issue in a relevant active repository (TSC perhaps?) and include a link back to this issue if this is a subject that should receive continued attention.