Discussion: Interest in segfault-handler

[No9]

Hey @nodejs/ctc
@fresheneesz raised an issue on segfault handler asking if we had discussed handing it over to core ddopson/node-segfault-handler#42 as the info you get for native module failures is a little more informative than the default in node.js.

I am not aware if it has been discussed previously but if it's something of interest then it would be great to make it happen

[bnoordhuis]

See #6734. It doesn't print backtraces on SIGSEGV or other fatal signals though, doing that from a signal handler is unsafe.

[fresheneesz]

@bnoordhuis Unsafe: how so?

[bnoordhuis]

There are only a limited number of things you are allowed to do in a signal handler, see the list of async-signal-safe functions in man 7 signal. Things like calling printf, malloc or dladdr are not on the list.

[fresheneesz]

@bnoordhuis Is that a limitation of v8 or something more fundamental?

[bnoordhuis]

It's a pretty fundamental limitation. Think of it like this: a signal arrives at an arbitrary time where the program can be in any state, including inconsistent or bad states.

As an example: printf and malloc generally grab locks to ensure proper synchronization. What happens when a signal arrives when the main program is inside a critical section and you try to re-enter that critical section again from the signal handler? Deadlock, data races, data corruption and segfaults are all possible.

[No9]

Thanks @bnoordhuis this is really useful so thanks for taking the time.
I think the usecase of being able to get rapid feedback during the development of a native module is valid but your insights into why you wouldn't want to do this in production are great.
I'm closing this and I will update the docs to mention the issues with it and recommend it for certain dev scenarios only.