Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cli: make ^C print a JS stack trace #24937

Closed
bnoordhuis opened this issue Dec 10, 2018 · 6 comments
Closed

cli: make ^C print a JS stack trace #24937

bnoordhuis opened this issue Dec 10, 2018 · 6 comments
Labels
cli Issues and PRs related to the Node.js command line interface. feature request Issues that request new features to be added to Node.js.

Comments

@bnoordhuis
Copy link
Member

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.
@joyeecheung
Copy link
Member

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

@targos
Copy link
Member

targos commented Dec 10, 2018

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

@targos targos added feature request Issues that request new features to be added to Node.js. cli Issues and PRs related to the Node.js command line interface. labels Dec 10, 2018
@joyeecheung
Copy link
Member

joyeecheung commented Dec 10, 2018

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?

@bnoordhuis
Copy link
Member Author

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.

@targos
Copy link
Member

targos commented Dec 10, 2018

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.

@bnoordhuis
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cli Issues and PRs related to the Node.js command line interface. feature request Issues that request new features to be added to Node.js.
Projects
None yet
Development

No branches or pull requests

3 participants