You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Node 10.0.0 fs.close is called with a second undefined argument. #20335
The documentation for fs.close states "No arguments other than a possible exception are given to the completion callback."
When used in conjunction with API's like async.waterfall, it is important that the callback is called with exactly one argument (err) because additional arguments are passed on to the next task.
I initially thought the issue might be due to recent changes in the makeCallback function, but that is not the case. The oncomplete handler is being called with a second undefined argument.
I see that there have been many changes to FSReqWrap in native land. Maybe the issue is in there somewhere?
In general, I would also only expect the callback to be called with a single argument. However, the language actually considers undefined as not existent so it should be fine.
Nevertheless, I think we should fix it and only return a single argument in the error case as we state in the documentation.
Trying to fix it but I keep getting a crash caused by errno being EBADF in uv__io_poll, and it only reproduces when I run the test in parallel. The test passes when being run alone though.
'use strict';// This tests that the fs APIs only passes error to the completion callback// if it's the only callback argument documented.constcommon=require('../common');constassert=require('assert');constfs=require('fs');consttmpdir=require('../common/tmpdir');constpath=require('path');tmpdir.refresh();constnonexistent=path.join(tmpdir.path,'noexistent');fs.open(nonexistent,'r',common.mustCall(function(...args){assert.strictEqual(args.length,1);common.expectsError({type: Error,code: 'ENOENT'})(args[0]);}));constfile=path.join(tmpdir.path,'file.txt');constcontent=Buffer.from('test');functiononOpen(...args){assert.deepStrictEqual(args[0],null);assert.strictEqual(args.length,2);constfd=args[1];assert.strictEqual(typeoffd,'number');fs.write(fd,content,common.mustCall(function(...args){assert.deepStrictEqual(args,[null,content.length,content]);fs.close(args[1],common.mustCall(function(...args){assert.deepStrictEqual(fs.readFileSync(file),content);assert.deepStrictEqual(args,[null]);}));}));}fs.open(file,'w+',common.mustCall(onOpen));
Assign to myself so I don't forget, although I am kind of puzzled by the EBADF since the patch only inlines the creation of Undefined for FSReqPromise and removes the undefined passed to the callbacks in AfterNoArgs (although the crash may be totally unrelated to this bug and just reveals another bug due to the way the test is written..)
Activity
tniessen commentedon Apr 26, 2018
cc @nodejs/fs
BridgeAR commentedon Apr 27, 2018
In general, I would also only expect the callback to be called with a single argument. However, the language actually considers
undefinedas not existent so it should be fine.Nevertheless, I think we should fix it and only return a single argument in the error case as we state in the documentation.
targos commentedon Apr 27, 2018
@joyeecheung maybe it's a side-effect of moving the errors from C++?
joyeecheung commentedon Apr 27, 2018
@targos It is introduced by #17689 actually. My guess is adding a no-argument overload for
FSReqWrap::Resolveshould fix itnode/src/node_file.cc
Line 478 in a1fc528
but I am not sure why undefined is resolved in the first place. cc @jasnell
joyeecheung commentedon Apr 27, 2018
Trying to fix it but I keep getting a crash caused by
errnobeingEBADFinuv__io_poll, and it only reproduces when I run the test in parallel. The test passes when being run alone though.See patch
See test
joyeecheung commentedon May 3, 2018
Assign to myself so I don't forget, although I am kind of puzzled by the
EBADFsince the patch only inlines the creation ofUndefinedforFSReqPromiseand removes theundefinedpassed to the callbacks inAfterNoArgs(although the crash may be totally unrelated to this bug and just reveals another bug due to the way the test is written..)src: remove 2nd `undefined` argument in node_file.cc
src: remove 2nd `undefined` argument in node_file.cc