Skip to content

workers: fix invalid exit code in parent upon uncaught exception #21713

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.

Sign up for GitHub

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

Closed
wants to merge 3 commits into from
Closed

workers: fix invalid exit code in parent upon uncaught exception #21713

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
483cdec
workers: fix invalid exit code in parent upon uncaught exception
lundibundi Jul 8, 2018
180abec
fixup! workers: fix invalid exit code in parent upon uncaught exception
lundibundi Jul 9, 2018
004c004
fixup! workers: fix invalid exit code in parent upon uncaught exception
lundibundi Jul 9, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions lib/internal/worker.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -445,6 +445,9 @@ function setupChild(evalScript) {

function fatalException(error) {
debug(`[${threadId}] gets fatal exception`);

process.exitCode = 1;
Copy link

@ciffelia ciffelia Jul 9, 2018

Choose a reason for hiding this comment

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

I'm afraid process.exitCode may be 1 even if the exception is caught.

Copy link
Member

@addaleax addaleax Jul 9, 2018

Choose a reason for hiding this comment

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

I agree – I think you want to move this into the if (!caught) block below?

Copy link
Member Author

@lundibundi lundibundi Jul 9, 2018

Choose a reason for hiding this comment

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

My bad, I assumed that this was unrecoverable (I thought 'uncaughtException' didn't count as recovery). Will push soon. I also added test similar to test-process-exit-code for workers.

Copy link
Member

@addaleax addaleax Jul 9, 2018 •
edited
Loading

Choose a reason for hiding this comment

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

I think behaviour should match the main thread’s behaviour as closely as possible – in there, we have that process.exitCode is not set, as far as I can tell:

process.on("uncaughtException", () => console.log(process.exitCode));
throw new Error();

prints undefined.

Copy link
Member

@addaleax addaleax Jul 9, 2018 •
edited
Loading

Choose a reason for hiding this comment

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

Copying the comment because Github currently hides it:

I think behaviour should match the main thread’s behaviour as closely as possible – in there, we have that process.exitCode is not set, as far as I can tell:

process.on("uncaughtException", () => console.log(process.exitCode));
throw new Error();

prints undefined.

I really think we just need to set process.exitCode in the if (!caught) block once.

Copy link
Member Author

@lundibundi lundibundi Jul 9, 2018 •
edited
Loading

Choose a reason for hiding this comment

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

That makes sense, but we should probably consider setting the code before calling handler (in both here and for process), to avoid current situation where it emits code 1 but process.exitCode has older value or undefined?
Edit: I mean in 'exit' event.

Copy link
Member

@addaleax addaleax Jul 9, 2018

Choose a reason for hiding this comment

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

@lundibundi I think that makes sense, yes. But since it affects all Node.js code, not just Workers, we probably should do it in a separate (and maybe even semver-major) PR.

The code you’d probably want to look at – if you want to tackle it yourself – is in process._fatalException in lib/internal/bootstrap/node.js and FatalException() in src/node.cc. We currently have hardcoded values for exiting in the latter function, so I think setting process.exitCode from exit handlers doesn’t have any effect at the moment?

Copy link
Member Author

@lundibundi lundibundi Jul 10, 2018

Choose a reason for hiding this comment

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

@addaleax Yeah, while looking into this one I looked though those functions (I actually first thought that exit code should be set on c++ side because we are listening on an exit callback from it).
From what I've seen both workers and process use node.cc/EmitExit which actually reevaluates exitCode after the event, so I think it will change the code. But indeed for the uncaught exception this is not the case, as it will always exit with 1 from FatalException() if it wasn't handled (or other hardcoded codes).
Should I open an issue first to track it or it should be okay to just submit PR?


let caught = false;
try {
caught = originalFatalException.call(this, error);
Expand Down
4 changes: 4 additions & 0 deletions test/parallel/test-worker-uncaught-exception-async.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,10 @@ if (!process.env.HAS_STARTED_WORKER) {
w.on('error', common.mustCall((err) => {
assert(/^Error: foo$/.test(err));
}));
w.on('exit', common.mustCall((code) => {
// uncaughtException is code 1
assert.strictEqual(code, 1);
}));
} else {
setImmediate(() => {
throw new Error('foo');
Expand Down
4 changes: 4 additions & 0 deletions test/parallel/test-worker-uncaught-exception.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,10 @@ if (!process.env.HAS_STARTED_WORKER) {
w.on('error', common.mustCall((err) => {
assert(/^Error: foo$/.test(err));
}));
w.on('exit', common.mustCall((code) => {
// uncaughtException is code 1
assert.strictEqual(code, 1);
}));
} else {
throw new Error('foo');
}