Repository navigation
Node report triggered by signal handler for SIGSEGV, SIGILL and other crashes. #81
Description
Activity
I thought the signal was configurable, intended for sending the signal from
kill SIG PID, but would it have worked once you knew node was segving?That probably won't work. The current signal handler code catches the signal then ensures that node-report runs on the event loop thread so it can call back into the isolate safely.
That's fine for a report triggered by the user sending a signal but it's not appropriate for a SIGSEGV (or similar) where the process is damaged and we have to be more careful about what we run. We would need to be quite careful about calling back into v8, and careful in general - there's a lot things you shouldn't do under a signal handler.
On limitation is that it might not be possible to get the JS stack in these cases but typically if a SIGSEGV is involved we'd be more interested in the native stack. We can use any information we gathered at npm load time like versions etc...
Raised PR #92 for this.
While debugging a test case for an npm with native code we found it was only crashing on one of our test machines.
If we had been able to do require('node-report') at the top of the test case and had signal handlers included as triggers for node-report we would have come away with a node-report file containing the native stack trace we needed to debug the issue immediately.
It turned out the test case was hard to replicate off the test machine as it was sensitive to compiler and OS versions and needed a perfectly matching environment.
Being able to have require('node-report') as standard at the top of a test case and immediately get useful debugging for a native crash would have moved this bug from consuming days of time to hours so I think this is probably an important use case and we should consider adding a SIGSEGV handler to node-report. (There may be other signals we want to catch too, depending on the platform.)