Node: cli: make ^C print a JS stack trace

Created on 10 Dec 2018  路  6Comments  路  Source: nodejs/node

It would be exceedingly nice for debugging non-responsive scripts if terminating the process with ^C / SIGINT prints a JS stack trace leading up to the currently executing code.

The use case is scripts stuck in (for example) infinite loops. Right now you don't really get an indication when that's happening except CPU usage in top.

It might be hard to pull off because signal handlers but maybe someone has a clever idea. My attempt at being clever:

  1. Route signals to a watchdog thread instead of the main thread
  2. Call isolate->RequestInterrupt() when a signal is received.
  3. Collect the stack trace in the interrupt handler.
  4. Either re-raise the signal on the main thread to terminate as usual, or raise a termination exception to kill the script.
cli feature request

Most helpful comment

If inspector is enabled, we don't need this. You can use the inspector API to pause the script and get the stack trace.

I'm aware. This is specifically for the case where the inspector is _not_ enabled.

I got the idea while working on some python code that occasionally got stuck. Tapping ^C and getting a useful stack trace is just amazingly useful.

Also either way we should already be able to do the watchdog refactoring even if we do not implement 3?

Yes, there are more reasons why a watchdog would be useful.

All 6 comments

Would it make more sense if we only do this when inspector is enabled? Or instead of SIGINT, use another signal.

If inspector is enabled, we don't need this. You can use the inspector API to pause the script and get the stack trace.

If inspector is enabled, we don't need this. You can use the inspector API to pause the script and get the stack trace.

Makes sense.

  1. Route signals to a watchdog thread instead of the main thread
  2. Call isolate->RequestInterrupt() when a signal is received.
  3. Collect the stack trace in the interrupt handler.
  4. Either re-raise the signal on the main thread to terminate as usual, or raise a termination exception to kill the script.

I remember there was a similar discussion when we were talking about implementing a special option for util.inspect to break when it's taking too long? The opinions were we should enable that as a global option instead of making it specific to util.inspect. Would a new CLI option (instead of --inspect) makes more sense for this?
Also either way we should already be able to do the watchdog refactoring even if we do not implement 3?

If inspector is enabled, we don't need this. You can use the inspector API to pause the script and get the stack trace.

I'm aware. This is specifically for the case where the inspector is _not_ enabled.

I got the idea while working on some python code that occasionally got stuck. Tapping ^C and getting a useful stack trace is just amazingly useful.

Also either way we should already be able to do the watchdog refactoring even if we do not implement 3?

Yes, there are more reasons why a watchdog would be useful.

I'm aware. This is specifically for the case where the inspector is not enabled.

I was replying to Joyee. I would really like to see a stack trace with ^C.

Fixed now that #29207 has (finally!) landed. Congrats, @legendecas!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ksushilmaurya picture ksushilmaurya  路  3Comments

filipesilvaa picture filipesilvaa  路  3Comments

jmichae3 picture jmichae3  路  3Comments

danialkhansari picture danialkhansari  路  3Comments

willnwhite picture willnwhite  路  3Comments