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

child_process: normalize fork function arguments #20882

Closed

Conversation

shobhitchittora
Copy link
Contributor

@shobhitchittora shobhitchittora commented May 22, 2018

Closes: #20749

  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines

arg typecheck test run - python ./tools/test.py parallel/test-child-process-spawn-typeerror.js

Affected subsystem(s)

child_process / fork

@nodejs-github-bot nodejs-github-bot added the child_process Issues and PRs related to the child_process subsystem. label May 22, 2018
@gireeshpunathil
Copy link
Member

potential user land breakage, so I suggest a CITGM run.

@shobhitchittora shobhitchittora changed the title child_process: normalize fork function arguments ( handling fork('task', undefined, {opts} ) child_process: normalize fork function arguments May 22, 2018
args === null ||
typeof args !== 'object')
) {
// throw new ERR_INVALID_ARG_TYPE('args', 'object', args);
Copy link
Contributor

Choose a reason for hiding this comment

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

This should be removed

} else if (typeof options !== 'object') {
throw new ERR_INVALID_ARG_TYPE('options', 'object', options);
} else {
options = {};
Copy link
Contributor

Choose a reason for hiding this comment

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

This is overwriting options if it is already an object or is null. My guess is this block is only meant for the latter case?

If so, perhaps this block should be removed completely and || options === null added to the first conditional that sets options = {}?

@shobhitchittora shobhitchittora force-pushed the fork-args-undefined-fix branch 2 times, most recently from fea8122 to a48fd21 Compare May 24, 2018 12:40
@shobhitchittora
Copy link
Contributor Author

@gireeshpunathil @mscdex I made the required change and tests are now passing on my local. Would like a CI and CIGTM re-run for this.

@gireeshpunathil
Copy link
Member

CI: https://ci.nodejs.org/job/node-test-pull-request/15076/
let us see how CI comes out, and then we will attack CIGTM.

@shobhitchittora
Copy link
Contributor Author

@gireeshpunathil some of the CIs are failing. This is the console outpot of node-test-commit-linux -

09:30:36 make[1]: *** [Makefile:448: test-ci] Error 1
09:30:36 make: *** [Makefile:473: run-ci] Error 2
09:30:37 Build step 'Execute shell' marked build as failure

Can you help me with this ? 😇Is this cause of the PR changes or something with the CI itself ?

@gireeshpunathil
Copy link
Member

actually, neither. Some of the failures (async-hooks/test-zlib.zlib-binding.deflate in Linux and parallel/test-child-process-fork-net on Windows) were failing off late for which there are open issues.

The error message you saw is a kind of summary in the bottom of the CI. To see the actual failure, you can go to the top of the page, and expand the full log button, and search for not ok

You may please go through all the failures and see if you are able to associate them with the PR. You can search in the repo with the base name of the failing file and see if they appear under issues, to know whether they are outstanding open issues.

Hope this helps!

Copy link
Member

@BridgeAR BridgeAR left a comment

Choose a reason for hiding this comment

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

I am not really sure why this moved into a separate function when it is only used in a single function. I personally would continue to keep it in there. That way we have no overhead.

There is also need to add a test for what this actually resolves.

@shobhitchittora
Copy link
Contributor Author

shobhitchittora commented May 24, 2018

@BridgeAR I guess separating it out make it more readable. There's a lot going in there and having reasonable moving parts makes it easier to reason about. Yeah but that's just me, do tell if this is okay. I can go ahead and add test for the function. Or else I can inline the function.

Cheers! 😇

@BridgeAR
Copy link
Member

I prefer to keep it in line in this case.

Copy link
Member

@BridgeAR BridgeAR left a comment

Choose a reason for hiding this comment

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

Please add test cases for what this should solve.

throw new ERR_INVALID_ARG_VALUE(`arguments[${pos}]`, arguments[pos]);
}
var args = arguments[1];
var options = arguments[2];
Copy link
Member

@BridgeAR BridgeAR May 25, 2018

Choose a reason for hiding this comment

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

Accessing arguments without checking the length can lead to OOB accesses. That is not that bad anymore but that requires quite some work for the compiler and it still slows things down. Therefore this way of doing it is not really good.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

would this be better -

var pos = 1;

var args = pos < arguments.length ? arguments[pos++] : [];
var options = pos < arguments.length ? arguments[pos++] : {};

Copy link
Member

Choose a reason for hiding this comment

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

Likely. Just try to make sure each code path is not hit more than absolutely necessary.

var options = arguments[2];

if (Array.isArray(args)) {
args = args.slice(0);
Copy link
Member

Choose a reason for hiding this comment

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

Is the slice needed? Please add a test case for it and remove it if there is no need for it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not sure. But for consistency I took inspiration from current implementation at -

args = args.slice(0);

Copy link
Member

Choose a reason for hiding this comment

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

That is not a strong argument. Please just verify this by adding a test as suggested.

} else if (options !== undefined &&
(args === undefined ||
args === null ||
typeof args !== 'object')
Copy link
Member

Choose a reason for hiding this comment

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

If args is not an object and it is not undefined or null, it should actually throw an error. Just ignoring the argument does not help anyone.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Adding a

throw new ERR_INVALID_ARG_VALUE('arg', 'object', options);

for the code you mentioned breaks this line in test -




Should we update this test and add assert.thorws for these cases.

Copy link
Member

Choose a reason for hiding this comment

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

No, the test cases would continue to work but the code has to be rewritten further.

@maclover7
Copy link
Contributor

ping @shobhitchittora

@maclover7 maclover7 added the wip Issues and PRs that are still a work in progress. label Aug 11, 2018
@shobhitchittora
Copy link
Contributor Author

Closing and opening a new one. Trying a simpler solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
child_process Issues and PRs related to the child_process subsystem. wip Issues and PRs that are still a work in progress.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants