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

src: adjust windows abort behavior to make sense #13947

Merged
merged 1 commit into from
Aug 8, 2017

Conversation

jkantr
Copy link
Contributor

@jkantr jkantr commented Jun 27, 2017

Raising SIGABRT is handled in the CRT in windows, calling _exit()
with ambiguous code "3" by default.

This adjustment to the abort behavior gives a more sane exit code
on abort, by calling _exit() directly with code 134.

I added a test I used initially in reference to recreating #12271 but it may be moot to merge.

Fixes: #12271
Refs: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/abort

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines
Affected core subsystem(s)

src

@nodejs-github-bot nodejs-github-bot added the c++ Issues and PRs that require attention from people who are familiar with C++. label Jun 27, 2017
@refack refack added process Issues and PRs related to the process subsystem. semver-major PRs that contain breaking changes and should be released in the next major version. labels Jun 27, 2017
@refack
Copy link
Contributor

refack commented Jun 27, 2017

Conservatively marking as semver-major.
Should it be considered semver-patch, since previous behaviour could be considered erroneous ?

@@ -21,7 +21,7 @@ function run(flags, signals) {
child.on('exit', common.mustCall(function(code, sig) {
if (common.isWindows) {
if (signals)
assert.strictEqual(code, 3);
assert.strictEqual(code, 3221225477);
Copy link
Contributor

Choose a reason for hiding this comment

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

Could you replace this with 0xC0000005 (better google results)

if (exports.isWindows)
expectedExitCodes = [3221225477, 3];
expectedExitCodes = [3221225477, 134];
Copy link
Contributor

Choose a reason for hiding this comment

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

Same 0xC0000005

@richardlau
Copy link
Member

@nodejs/platform-windows

@refack
Copy link
Contributor

refack commented Jun 27, 2017

@jkantr One request, add 134 as an example in the last note in https://github.com/nodejs/node/blob/master/doc/api/process.md#exit-codes

@refack
Copy link
Contributor

refack commented Jun 27, 2017

/cc @nodejs/release how do we decide the semver level?

}

// --max-old-space-size=3 is the min 'old space' in v8, explodes fast
const cmd = `"${process.argv[0]}" --max-old-space-size=3 "${process.argv[1]}"`;
Copy link
Member

Choose a reason for hiding this comment

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

This could use process.execPath and __filename.

fn(2);
}

// --max-old-space-size=3 is the min 'old space' in v8, explodes fast
Copy link
Member

Choose a reason for hiding this comment

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

Small nit: v8 -> V8. This will help distinguish between Node.js 8 and V8 JavaScript engine.


// --max-old-space-size=3 is the min 'old space' in v8, explodes fast
const cmd = `"${process.argv[0]}" --max-old-space-size=3 "${process.argv[1]}"`;
exec(`${cmd} heapBomb`, (err) => {
Copy link
Member

Choose a reason for hiding this comment

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

Please wrap the callback with common.mustCall().

const cmd = `"${process.argv[0]}" --max-old-space-size=3 "${process.argv[1]}"`;
exec(`${cmd} heapBomb`, (err) => {
const msg = `Wrong exit code of ${err.code}! Expected 134 for abort`;
assert.strictEqual(err.code, 134, msg);
Copy link
Member

Choose a reason for hiding this comment

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

Might be worth a short comment explaining why common.nodeProcessAborted() is not used.

@refack refack added the windows Issues and PRs related to the Windows platform. label Jun 27, 2017
@refack refack self-assigned this Jun 27, 2017
@gireeshpunathil
Copy link
Member

#node --v8-options | grep "abort_on_uncaught_exception"
  --abort_on_uncaught_exception (abort program (dump core) when an uncaught exception is thrown)
#
  1. Will this change imply the phrase dump core will not be honored? I have no evidence that Windows dumps core on abort (Windows internals has been bit grey for me) but just wondering what is the difference with and without the flag in Windows, if a core is not produced.

If we cannot prove either way (ability / inability to configure Windows to collect dump on abort) I suggest we document on the lines of :
--abort_on_uncaught_exception does not dump in Windows.
It may be the current behavior as well, but now by exiting, we are closing out all the possibilities.

  1. Programs that embed node and programs that spawn node may have static assumptions about the current behavior of abort / exit code, so this change warrants semver-major I guess.

@refack
Copy link
Contributor

refack commented Jun 29, 2017

If we cannot prove either way (ability / inability to configure Windows to collect dump on abort) I suggest we document on the lines of :

This change will stop windows from even attempting a core dump. It could be restored with an explicit call to MiniDumpWriteDump

@gireeshpunathil
Copy link
Member

@refack - right, so the question is: do we follow the doc (abort program with dump on uncaught exception) or make this change and amend the doc to that effect.

My point is: if Windows never dumped a core on aborted node before, or we don't know of anyone reporting that as an issue, I think we are good with this change, with the doc reflecting the change. If we get issues that require dump inspection, we can always bring an in-process dumping feature through MiniDumpWriteDump. Thoughts?

@refack
Copy link
Contributor

refack commented Jun 29, 2017

/cc @nodejs/post-mortem
@billti @AndrewPardoe does the VS team have an opinion on node core dumps (In Windows)?

@bzoz
Copy link
Contributor

bzoz commented Jun 29, 2017

On Windows libuv disables WER and thus also dumping cores (src/win/core.c:177). From a quick search it looks like it is not enabled anywhere else in the codebase.

@gireeshpunathil
Copy link
Member

thanks @bzoz . And that piece of code is around there since 2011, so we are good in terms of core dump. in terms of doc - while it looks clean to state this fact explicitly, I am fine with this change as it is.

@gireeshpunathil
Copy link
Member

@gireeshpunathil
Copy link
Member

test failures seem unrelated:
pi3-raspbian-jessie: not ok 67 parallel/test-fs-readdir-ucs2
win2008r2: not ok 177 parallel/test-icu-data-dir
both of which passed later

FYI - @refack

@tniessen
Copy link
Member

@gireeshpunathil Yes, these are known problems, even though the latter should be fixed now, ref #13986.

@refack
Copy link
Contributor

refack commented Jun 30, 2017

@refack
Copy link
Contributor

refack commented Jun 30, 2017

RE last massage: black magic still works after this PR 👍
Fresh CI: https://ci.nodejs.org/job/node-test-commit/10840/

ping @nodejs/ctc PTAL, this needs another review

@gireeshpunathil
Copy link
Member

@refack - great, that is a good news! Where do I set the Silent Exit Flag? gflags.exe? I could not locate it in any of my Win 7/10 systems. Is it an external download?

@refack
Copy link
Contributor

refack commented Jun 30, 2017

Where do I set the Silent Exit Flag? gflags.exe?

gflags.zip

The "good" gflags.exe is part of the 8.1 SDK - C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64
The one that comes with the 10 SDK has no GUI.

@refack
Copy link
Contributor

refack commented Jul 9, 2017

CI to make sure it's still fresh: https://ci.nodejs.org/job/node-test-pull-request/9052/
@nodejs/ctc need another review, PATL

@refack
Copy link
Contributor

refack commented Jul 25, 2017

@nodejs/ctc this needs another review, PTAL

@Trott
Copy link
Member

Trott commented Jul 25, 2017

Aside: The wait to get CTC reviews for this may be a sign that we need more Windows representation on CTC.

Copy link
Member

@mhdawson mhdawson left a comment

Choose a reason for hiding this comment

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

As long as its SemVer Major seems good to me.

@refack
Copy link
Contributor

refack commented Aug 1, 2017

@refack
Copy link
Contributor

refack commented Aug 2, 2017

@jkantr after the long wait we got the 2 CTC approval, but a failing test came up could you take a look?

not ok 1 async-hooks/test-callback-error
  ---
  duration_ms: 0.631
  severity: fail
  stack: |-
    start case 1
    end case 1: 131.106ms
    start case 2
    end case 2: 130.250ms
    start case 3
    end case 3: 6.412ms
    assert.js:42
      throw new errors.AssertionError({
      ^
    
    AssertionError [ERR_ASSERTION]: 134 === 3
        at ChildProcess.child.on (c:\workspace\node-test-binary-windows\RUN_SUBSET\0\VS_VERSION\vcbt2015\label\win10\test\async-hooks\test-callback-error.js:104:14)
        at emitTwo (events.js:125:13)
        at ChildProcess.emit (events.js:213:7)
        at maybeClose (internal/child_process.js:929:16)
        at Process.ChildProcess._handle.onexit (internal/child_process.js:212:5)
  ...

@Trott
Copy link
Member

Trott commented Aug 7, 2017

This has two CTC approvals, etc. Any reason this shouldn't land?

@refack
Copy link
Contributor

refack commented Aug 7, 2017

There's still one failing test, but I've talked to @jkantr about it...

@jkantr jkantr force-pushed the win32-heap-abort-code branch from 042bf12 to f4186dc Compare August 8, 2017 01:37
@refack
Copy link
Contributor

refack commented Aug 8, 2017

@refack
Copy link
Contributor

refack commented Aug 8, 2017

All CI fails are known flakes or infra problems

@refack refack force-pushed the win32-heap-abort-code branch from f4186dc to 8f6b762 Compare August 8, 2017 02:44
Raising SIGABRT is handled in the CRT in windows, calling _exit()
with ambiguous code "3" by default.

This adjustment to the abort behavior gives a more sane exit code
on abort, by calling _exit directly with code 134.

PR-URL: nodejs#13947
Fixes: nodejs#12271
Refs: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/abort
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
@refack refack force-pushed the win32-heap-abort-code branch from 8f6b762 to 80ebb42 Compare August 8, 2017 02:46
@refack refack merged commit 80ebb42 into nodejs:master Aug 8, 2017
@refack
Copy link
Contributor

refack commented Aug 8, 2017

Landed in 80ebb42
@jkantr congrats on being GitHub promoted from
image
to
image

@refack
Copy link
Contributor

refack commented Aug 8, 2017

Extra sanity test on master: https://ci.nodejs.org/job/node-test-commit-linuxone/7813/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c++ Issues and PRs that require attention from people who are familiar with C++. process Issues and PRs related to the process subsystem. semver-major PRs that contain breaking changes and should be released in the next major version. windows Issues and PRs related to the Windows platform.
Projects
None yet
Development

Successfully merging this pull request may close these issues.