Post mortem alternatives

[spion]

One of the suggested solutions to get proper post mortem core dumps is to only run promise handlers from the microtask queue in a try/catch block if a catch handler has already been added to the promise synchronously, when --abort-on-unhandled-rejection is passed as an argument.

Problems:

1. Breaks the promise constructor as well as existing promise code. With this implemented, existing libraries are just as likely to generate core dumps as the problem code we're trying to trace down. To prevent this, node would have to add logging of warnings for unhandled rejections when catch handlers are added asynchronously - a huge shift in the current promise ecosystem.
2. Wont work with generator-based solutions and generator-based async/await transpilers. The generator runners have to attach a catch handler to the promise to forward that to the generator, and they have no way of querying generators whether the current frame is within a try-catch block
3. Promises are designed to be used with try/catch. As such there will be little point in giving promises to users while forbidding them to use try/catch, especially with async/await or generators. Only if filtered catch is added to the language, then this change will start making sense.
   • proposed avoidance method: passing an object as a second argument is not ergonomic and against core promise point (error propagation)
   • alternate method: promise[methodNameToBeDetermined](predicate, handlerReturningPromise) would work better, but still misses the point of using async/await.

This issue is opened to discuss alternatives that may satisfy post mortem debugging needs.

[spion]

Proposal by petka: different kind of dump that can be consumed by Chrome debugger.

The chrome debugger supports long stack traces as well as inspection of the current state of running JS code. In theory it may be possible to make v8 dump a loadable core even after a delay and "reconstruct" the previous stack (?)

Cons:

• requires patch to V8
  • petka: might be doable if we can convince chrome developers its useful in the browser ("Send crash report to developer?")
• requires patch to chrome dev tools
• native modules stack trace
  • would it be an acceptable compromise not to have that for promises?
• 1 tick delayed picture of data (there could be changes in theory)
  • would this be acceptable?
  • bigger delay for earlier traces in the "long" stack trace
  • because of the delay, will it be possible to inspect:
    • arguments?
    • local variables? (GC concerns)

Pros:

• access to entire long stack, including previous events
• cross-OS, platform independent.
• doesn't require that users avoid try/catch
• works with most existing promise code

[petkaantonov]

I had an idea of proprietary v8 core dumps that could be opened in Chrome debugger and debugged just as well as you can debug chrome web apps live in development. Advantages that immediately come to mind over native core dump is that the debugger is javascript aware and you get long stack traces.

However it might not be feasible to run in production due to performance and space requirement.

[benjamingr]

Don't Chrome async stack traces significantly slow things down?

[petkaantonov]

Yes and even if you are ok without having long stack traces, such mechanism still needs to be used so that proper core dump can be made after the actual original stack is gone

[petkaantonov]

Actually short stack traces might be very feasible as you don't actually need to collect them until an error happens. And long stack traces could still be separately enabled for production where performance isn't critical.

[vkurchatkin]

I had an idea of proprietary v8 core dumps that could be opened in Chrome debugger and debugged just as well as you can debug chrome web apps live in development.

How is it different from actual core dumps? There are already v8-aware plugins for popular debuggers. Debugging with chrome tools would be nice, but it as far as I know it requires only debugging protocol implementation, nothing more.

[petkaantonov]

Chrome debugger is more accessible and familiar to web developers, it's same software that works cross platform and you can get long stack traces rather than just the last event.

See also #8 (comment)

[spion]

@vkurchatkin admittedly its a far fetched idea, but basically combining some sort of a dump file with this:

http://www.html5rocks.com/en/tutorials/developertools/async-call-stack/

[rvagg]

Related nodejs/node#2546, it could be worthwhile connecting with the folks involved in this work (I'm assuming it's going on now, just slowly) and we may come out the other end of that process with something everyone can love.

[pavelfeldman]

We are about to change the way async stacks are collected in Chrome DevTools. As of today, we capture the "debug" stacks that include live scope objects and hence slow down things / leak memory.

It adds more complexity than value, so we are thinking about migrating to the v8 api for async stacks. Users would still have complete async stack chain, but would no longer be able evaluate on the async stack frames.

This makes us more conservative wrt memory use and we can make the async stack depth configurable so that clients could manage the perf overhead on their own.

[benjamingr]

@repenaxa thanks for dropping by :)

• Would the value of this and arguments be available?
• Would it be available at the time the error happened?
• Would there be a way to "snapshot" the objects at the time the exception happened? (Vs when the asynchronous unhandled rejection was detected)