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

Race condition in test-fs-read-stream-fd-leak.js #3215

Closed
john-yan opened this issue Oct 6, 2015 · 1 comment
Closed

Race condition in test-fs-read-stream-fd-leak.js #3215

john-yan opened this issue Oct 6, 2015 · 1 comment
Labels
fs Issues and PRs related to the fs subsystem / file system. test Issues and PRs related to the tests.

Comments

@john-yan
Copy link

john-yan commented Oct 6, 2015

https://github.com/nodejs/node/blob/master/test/parallel/test-fs-read-stream-fd-leak.js

The intermittent assertion failure could be fired as follows:
assert.js:89
throw new assert.AssertionError({
^
AssertionError: no leaked file descriptors using destroy() (got 5)
at null._onTimeout (/sandbox/johnyan/github-node/test/parallel/test-fs-read-stream-fd-leak.js:37:16)
at Timer.listOnTimeout (timers.js:89:15)

The race condition is spotted in the following code:

    if (++i === loopCount) {
      clearTimeout(this);
      setTimeout(function() {
        assert.equal(0, openCount, 'no leaked file descriptors using ' +
                     endFn + '() (got ' + openCount + ')');
        openCount = 0;
        callback && setTimeout(callback, 100);
      }, 100);
    }

In the failing case, the first setTimeout function is fired before all streams are properly closed. If reduce the setTimeout period (say from 100 to 1), the failure rate is increased. Depends on the running environment (slow/fast), the failure rate varies. Can anyone suggest a better solution to this?

@silverwind silverwind added fs Issues and PRs related to the fs subsystem / file system. test Issues and PRs related to the tests. labels Oct 6, 2015
@mhdawson
Copy link
Member

mhdawson commented Oct 6, 2015

I think we are going to need a timeout as its the only way to give a good message in the case of the failure case when we don't get the expected close (the other option is to let the test hang and have the harness time it out but that does not give us the opportunity to provide additional info). What I'd suggest is that we have a longer timeout before generating an error but that we check at a shorter interval for the success case so that the test runs quickly unless an failure occurs

jasnell pushed a commit that referenced this issue Oct 8, 2015
Fix intermittent test failure on slower machines.
Gives test longer time to complete but checks
at regular intervals so that the test only
runs longer on slower machines or in the failure
case.

PR-URL: #3218
Fixes: #3215
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: James Snell <jasnell@gmail.com>>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fs Issues and PRs related to the fs subsystem / file system. test Issues and PRs related to the tests.
Projects
None yet
Development

No branches or pull requests

3 participants