This repository was archived by the owner on Mar 31, 2018. It is now read-only.
Repository navigation
This repository was archived by the owner on Mar 31, 2018. It is now read-only.
Post mortem alternatives #8
Description
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:
- 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.
- Wont work with generator-based solutions and generator-based
async/awaittranspilers. 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 - 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 withasync/awaitor 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.
Activity
spion commentedon Feb 15, 2016
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:
Pros:
petkaantonov commentedon Feb 15, 2016
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 commentedon Feb 15, 2016
Don't Chrome async stack traces significantly slow things down?
petkaantonov commentedon Feb 15, 2016
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 commentedon Feb 15, 2016
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 commentedon Feb 15, 2016
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 commentedon Feb 15, 2016
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 commentedon Feb 16, 2016
@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 commentedon Feb 16, 2016
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 commentedon Feb 16, 2016
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 commentedon Feb 17, 2016
@repenaxa thanks for dropping by :)
thisandargumentsbe available?