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: execFile and fork arg parsing ambiguity #2681

Closed
jasnell opened this issue Sep 3, 2015 · 5 comments
Closed

child_process: execFile and fork arg parsing ambiguity #2681

jasnell opened this issue Sep 3, 2015 · 5 comments
Labels
child_process Issues and PRs related to the child_process subsystem.

Comments

@jasnell
Copy link
Member

jasnell commented Sep 3, 2015

See: #2667 (comment)

When it lands, #2667 will bring over the v0.12 changes that improved argument parsing in child_process execFile and fork. However, even with that change, argument parsing is still too ambiguous and ought to be tightened up. For instance, execFile('ls',{a:1},'test') goes through without a throw even tho a string is passed in for the callback. Internally, execFile just acts as if the callback wasn't provided at all. Likewise, execFile('ls',[], 'test', function() {}) does not throw either. Nor does execFile('ls',[],'test','test'). The only type that is actually checked is the args, so that if you pass in execFile('ls', 'test'), a TypeError will throw.

For v4.0.0, the priority is on landing #2667 to ensure parity with v0.12, but moving forward we'll want to tighten up the argument parsing here (and likely in other places as well).

@trevnorris (@nodejs/api)

@ChALkeR ChALkeR added the child_process Issues and PRs related to the child_process subsystem. label Sep 3, 2015
@ChuckLangford
Copy link
Contributor

@jasnell: Would you rather see the argument parsing in execFile be replaced? Or just made more complete?

@jasnell
Copy link
Member Author

jasnell commented Dec 28, 2015

Either really. If there's going to be argument checking it needs to be consistent.

@ChuckLangford
Copy link
Contributor

@jasnell: So I was running through the contribution guide and I got up to the testing section. I'm seeing odd behavior that I'm hoping you can clear up for me. I ran ./configure && make -j8 test and everything passed. I ran the same command without a code change and I started seeing errors. When I ran the same command for a third time, it ran without error.

I then switched to the unaltered and up-to-date master branch and ran the same command multiple times. Master also exhibited the same behavior.

Before I go diving into tests that are seemingly unrelated, can you tell me if this is a known issue?

Here's an example of a few of the errors I'm seeing. The errors themselves are inconsistent too; different builds result in different errors.

=== release test-net-connect-local-error ===
Path: parallel/test-net-connect-local-error
assert.js:89
  throw new assert.AssertionError({
  ^
AssertionError: undefined == 12346
    at Socket.onError (/node/test/parallel/test-net-connect-local-error.js:13:10)
    at Socket.<anonymous> (/node/test/common.js:395:15)
    at emitOne (events.js:78:13)
    at Socket.emit (events.js:170:7)
    at emitErrorNT (net.js:1258:8)
    at nextTickCallbackWith2Args (node.js:470:9)
    at process._tickCallback (node.js:384:17)
Command: out/Release/node /node/test/parallel/test-net-connect-local-error.js



=== release test-cluster-net-send ===
Path: parallel/test-cluster-net-send
[23511] master
[23519] worker

assert.js:89
  throw new assert.AssertionError({
  ^
AssertionError: false == true
    at process.<anonymous> (/node/test/parallel/test-cluster-net-send.js:29:12)
    at process.g (events.js:264:16)
    at emitOne (events.js:83:20)
    at process.emit (events.js:170:7)
Command: out/Release/node /node/test/parallel/test-cluster-net-send.js

@jasnell
Copy link
Member Author

jasnell commented Dec 31, 2015

There are some tests that are known to be flaky on some operating systems.
If you're seeing inconsistent behavior, you've likely stumbled upon one.
The easiest thing to do to confirm is to open an issue describing the
behavior you're seeing and see if others have seen the same behavior.
On Dec 30, 2015 1:48 PM, "Chuck Langford" notifications@github.com wrote:

@jasnell https://github.com/jasnell: So I was running through the
contribution guide and I got up to the testing section. I'm seeing odd
behavior that I'm hoping you can clear up for me. I ran ./configure &&
make -j8 test and everything passed. I ran the same command without a
code change and I started seeing errors. When I ran the same command for a
third time, it ran without error.

I then switched to the unaltered and up-to-date master branch and ran the
same command multiple times. Master also exhibited the same behavior.

Before I go diving into tests that are seemingly unrelated, can you tell
me if this is a known issue?

Here's an example of a few of the errors I'm seeing. The errors themselves
are inconsistent too; different builds result in different errors.

=== release test-net-connect-local-error ===
Path: parallel/test-net-connect-local-error
assert.js:89
throw new assert.AssertionError({
^
AssertionError: undefined == 12346
at Socket.onError (/node/test/parallel/test-net-connect-local-error.js:13:10)
at Socket. (/node/test/common.js:395:15)
at emitOne (events.js:78:13)
at Socket.emit (events.js:170:7)
at emitErrorNT (net.js:1258:8)
at nextTickCallbackWith2Args (node.js:470:9)
at process._tickCallback (node.js:384:17)
Command: out/Release/node /node/test/parallel/test-net-connect-local-error.js

=== release test-cluster-net-send ===
Path: parallel/test-cluster-net-send
[23511] master
[23519] worker

assert.js:89
throw new assert.AssertionError({
^
AssertionError: false == true
at process. (/node/test/parallel/test-cluster-net-send.js:29:12)
at process.g (events.js:264:16)
at emitOne (events.js:83:20)
at process.emit (events.js:170:7)
Command: out/Release/node /node/test/parallel/test-cluster-net-send.js


Reply to this email directly or view it on GitHub
#2681 (comment).

ChuckLangford added a commit to ChuckLangford/node that referenced this issue Jan 12, 2016
The argument parsing for execFile and fork are inconsistent. execFile
throws on one invalid argument but not others. fork has similar logic
but the implementation is very different. This update implements
consistency for both functions.

Fixes: nodejs#2681
@Trott
Copy link
Member

Trott commented Jun 24, 2016

Proposed fix in #7399

Trott added a commit to Trott/io.js that referenced this issue Jun 27, 2016
Trott pushed a commit to Trott/io.js that referenced this issue Jun 30, 2016
Fixes: nodejs#2681
Refs: nodejs#4508
PR-URL: nodejs#7399
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
@Trott Trott closed this as completed in 0548e5d Jun 30, 2016
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.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants