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

[feature] Write data to file on SIGINT unless specified #11

Closed
wants to merge 2 commits into from

Conversation

Fishrock123
Copy link
Collaborator

Allows better debugging of applications that have handles that are preventing them from closing.

@@ -147,7 +147,17 @@ asyncHook.enable();
// Print result
//

process.on('exit', function () {
if (process.argv.indexOf('--raw-sigint') === -1 ||
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perhaps call it --dprof-sigint. The raw part doesn't really make sense to me.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also shouldn't this be !== -1.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, the logic is correct -- I think it is better UX to have it as the default, as I suspect that is what most folks will expect.

That's also why I called it --raw-sigint, as in, don't touch the default.

It could be something like --no-sigint-handler or --no-dprof-sigint.

The ENV variable exists for programs that may error on new flags.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should it not be !process.env.DPROF_RAW_SIGINT then?

@AndreasMadsen
Copy link
Owner

AndreasMadsen commented Aug 27, 2016

Thanks. You should document this.

I guess it is not easy to test with the my odd testrunner, but at the very least you can have the script signal itself.

// one of these
process.argv.push('--raw-sigint');
process.env.DPROF_RAW_SIGINT = '';
require('../../dprof.js');

setInterval(function () {}, 1000):
setTimeout(function () {
  process.kill(process.pid, 'SIGINT');
}, 200);

to make the test work:

  1. add the script file (e.g. sigint-env.json) under scripts
  2. add an empty json file (e.g. sigint-env.json) under expected
  3. edit update to true in test/test.js (and back when your done).
  4. run npm test
  5. check the output manually
  6. check the output visually using node test/show.js sigint-env.

@Fishrock123
Copy link
Collaborator Author

Fishrock123 commented Aug 27, 2016

@AndreasMadsen updated

screen shot 2016-08-27 at 10 38 39 am

@@ -147,7 +147,17 @@ asyncHook.enable();
// Print result
//

process.on('exit', function () {
if (process.argv.indexOf('--dprof-no-sigint') === -1 ||
process.env.DPROF_NO_SIGINT) {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, the logic is correct -- I think it is better UX to have it as the default, as I suspect that is what most folks will expect.

Should it not be !process.env.DPROF_NO_SIGINT then?

@Fishrock123
Copy link
Collaborator Author

@AndreasMadsen yup, good catch. Fixed I think.

!process.env.DPROF_NO_SIGINT) {
process.on('SIGINT', () => {
writeDataFile();
process.exit();
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This indicates a successful exit, however when I SIGINT a process I get the exit code 130. According to http://unix.stackexchange.com/questions/99112/default-exit-code-when-process-is-terminated exit codes >= 128 indicates the process exited because of a signal.

I don't know if that is the case here, but surely the exit code should be >= 1.

@Fishrock123
Copy link
Collaborator Author

Hmmm, the test doesn't seem to fail with either the flag or variable uncommented, not really sure what's up.

@AndreasMadsen
Copy link
Owner

AndreasMadsen commented Aug 27, 2016

Hmmm, the test doesn't seem to fail with either the flag or variable uncommented, not really sure what's up.

I've done a more thorough review ...

  • process.on('exit') is called when process.exit() is called from SIGINT causing two dumps.
  • process.env.DPROF_NO_SIGINT = '' is falsy, we need to use !process.env.hasOwnProperty('DPROF_NO_SIGINT')
  • if either --dprof-no-sigint or DPROF_NO_SIGINT exists, the if statement shouldn't run. This means that || should be &&. (De Morgan's laws in formal logic :p).

@AndreasMadsen
Copy link
Owner

AndreasMadsen commented Aug 27, 2016

I've also updated the test runner to be more sensitive to some of these issues and more robust to other. There are some conflicts, I think you can just drop 8fc3cb7 and create a new one.

@Fishrock123
Copy link
Collaborator Author

process.on('exit') is called when process.exit() is called from SIGINT causing two dumps.

Arrgh, right. I did some tracing of where the current node behavior comes from, and found this old issue. Apparently generically calling exit handles is a bad idea. I'm not actually sure how to exit without calling them... process.abort() could do but that produces a core file if possible...

@AndreasMadsen
Copy link
Owner

AndreasMadsen commented Aug 29, 2016

Arrgh, right. I did some tracing of where the current node behavior comes from, and found this old issue. Apparently generically calling exit handles is a bad idea. I'm not actually sure how to exit without calling them... process.abort() could do but that produces a core file if possible...

"some digging", wow that is a very old issue :) A crazy idea is to remove all SIGINT handlers and have the process SIGINT itself. But I'm also fine with just calling process.exit().

Allows better debugging of applications that have handles that are
preventing them from closing.
@Fishrock123
Copy link
Collaborator Author

Some things:

Note sure why Signal says NaN for these:

screen shot 2016-08-30 at 11 12 47 am

Also, should we disable asyncHook around our own Signal handler so that it doesn't show up?

@AndreasMadsen
Copy link
Owner

Note sure why Signal says NaN for these.

Thought I fixed that. The wait part is because the destroy property is null (happens when the destroy doesn't fire). The solution is to use root.total time instead when destroy: null (code: https://github.com/AndreasMadsen/dprof/blob/master/visualizer/info.js#L40). It is not related to this PR so lets fix that separately, I would like this to land.

I don't know why callback is NaN too.

Also, should we disable asyncHook around our own Signal handler so that it doesn't show up?

Was, thinking about that too. If Signal handler isn't reused by another on('SIGINT') then its safe. But if it is reused then we are removing some information from the user. It may not be a big problem, as the user can pass --dprof-no-sigint for full transparency. What do you think?

@Fishrock123
Copy link
Collaborator Author

The Signal handling code is at https://github.com/nodejs/node/blob/master/lib/internal/process.js#L180-L219

tl;dr: they are shared.

Maybe we should just go with this for now then?

AndreasMadsen pushed a commit that referenced this pull request Aug 30, 2016
Allows better debugging of applications that have handles that are
preventing them from closing.

PR: #11
AndreasMadsen pushed a commit that referenced this pull request Aug 30, 2016
@AndreasMadsen
Copy link
Owner

The Signal handling code is at https://github.com/nodejs/node/blob/master/lib/internal/process.js#L180-L219

Thanks for looking that up.

Maybe we should just go with this for now then?

Definitely. Landed in 2548239 ee3ee18 – Note I rename the test from sigint-env to just sigint.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants