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
Thanks all for being on the call yesterday and for being willing to answer my questions around Node crash reporting. Specifically, I am interested in a few things. I want to get better knowledge of how crash reporting works, and whether or not I can send crash reports to a third party. I'm interesting in solutions to how users get and send their crash reports from Node and Electron (which I realize is out of scope for this project) to developers, especially when there are Node native plugins involved.
Is there a better place to ask these questions?
Is there any way to hook into internal Node APIs for a third party vendor of crash reports?
Does --experimental-report use a third party vendor to create reports? Is it possible to choose a different module or vendor to create crash reports?
Where in the Node.js core codebase is the code for crash reporting, in general?
For people using Node native plugins, what do crash reports look like? Are they the same as using Node, in general? I may be misunderstanding what node native plugins are.
As far as I can tell, there are two exits from Node when a crash happens: an uncalled exception, or an unhandled Promise rejection. Does this sound right?
Is there a way to add a plugin to N-API or nan in order to compile crash reports?
Any resources for the industry standard on Node native crash reporting?
If any of these questions unintelligible or phrased badly, it's possibly because my lack of knowledge makes framing poor. Let me know if that seems to be the case!
I guess nodejs/node (core), nodejs/help (help) too, but probably same set of folks will answer, so this place looks great!
Is there any way to hook into internal Node APIs for a third party vendor of crash reports?
Probably if you could expand a little here? I am able to see multiple cases, but better wait for your clarification rather than guessing.
Does --experimental-report use a third party vendor to create reports? Is it possible to choose a different module or vendor to create crash reports?
No, the report is fully part of node core. The original idea was from https://www.npmjs.com/package/node-report which now is maintained under nodejs organization, but the current functionality that is exposed through the said flag is fully part of the nodejs/node project with no third party dependency
Where in the Node.js core codebase is the code for crash reporting, in general?
Is it possible to use --experimental-report in an Electron app?
I guess so, though I haven't tried. You might need to export NODE_OPTIONS with the report flags, in the shell where you spin up the app
Are there issues with containers storing these logs nodejs/node#31576? Are these the same question?
No known issues with containers storing report logs. The said issue seems to be different.
For people using Node native plugins, what do crash reports look like? Are they the same as using Node, in general? I may be misunderstanding what node native plugins are.
They are same.
As far as I can tell, there are two exits from Node when a crash happens: an uncalled exception, or an unhandled Promise rejection. Does this sound right?
Yes. (may be some expansion may help, if anyone wants to?)
Is there a way to add a plugin to N-API or nan in order to compile crash reports?
cc @nodejs/n-api
Any resources for the industry standard on Node native crash reporting?
As far as I can tell, there are two exits from Node when a crash happens: an uncalled exception, or an unhandled Promise rejection. Does this sound right?
An unhandled Promise rejection will not exit the Node.js process by default. There's a flag to set this behavior though (--unhandled-rejections=strict).
Native (C++) crashes will also cause the process to exit.
Reacted by Gireesh Punathil, Richard Littauer and Bobby Galli
I took a look at #295, and left a comment there thinking how I can move that forward. Hope it helps!
As for my questions above - I think your answers actually answered the questions for the team I was working with. As this isn't actionable, I am going to close it. I hope others are able to find use out of this, too. If any of this could or should be merged into any FAQ-like docs (should we make an FAQ.md doc?) to hep others out, let me know.
Activity
gireeshpunathil commentedon Mar 12, 2020
@RichardLitt - thanks for these great questions!
I guess nodejs/node (core), nodejs/help (help) too, but probably same set of folks will answer, so this place looks great!
Probably if you could expand a little here? I am able to see multiple cases, but better wait for your clarification rather than guessing.
No, the report is fully part of node core. The original idea was from https://www.npmjs.com/package/node-report which now is maintained under nodejs organization, but the current functionality that is exposed through the said flag is fully part of the nodejs/node project with no third party dependency
code: https://github.com/nodejs/node/blob/master/src/node_report.h
doc: https://nodejs.org/dist/latest-v13.x/docs/api/report.html
I guess so, though I haven't tried. You might need to export NODE_OPTIONS with the report flags, in the shell where you spin up the app
No known issues with containers storing report logs. The said issue seems to be different.
They are same.
Yes. (may be some expansion may help, if anyone wants to?)
Is there a way to add a plugin to N-API or nan in order to compile crash reports?
cc @nodejs/n-api
we are trying to build one, please review #295
I hope I provided answers to some, but feel free to expand on wherever things lack, I or other can help explaining
mmarchini commentedon Mar 12, 2020
An unhandled Promise rejection will not exit the Node.js process by default. There's a flag to set this behavior though (
--unhandled-rejections=strict).Native (C++) crashes will also cause the process to exit.
RichardLitt commentedon Mar 14, 2020
Thank you, @mmarchini and @gireeshpunathil! This is really quite helpful.
I'm following up with my team on all of these, and will get back to you! I apologise for the delay here. :)
RichardLitt commentedon Apr 21, 2020
@gireeshpunathil Thank you, again.
I took a look at #295, and left a comment there thinking how I can move that forward. Hope it helps!
As for my questions above - I think your answers actually answered the questions for the team I was working with. As this isn't actionable, I am going to close it. I hope others are able to find use out of this, too. If any of this could or should be merged into any FAQ-like docs (should we make an FAQ.md doc?) to hep others out, let me know.
gireeshpunathil commentedon Apr 22, 2020
Looks like a great idea to me. Shall we discuss this in the WG? (probably needs an issue in itself)
RichardLitt commentedon May 8, 2020
Let me know if it is. Happy to stub out a PR.