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

test: test for issue #5574 #5841

Closed
wants to merge 5 commits into from
Closed

test: test for issue #5574 #5841

wants to merge 5 commits into from

Conversation

piranna
Copy link
Contributor

@piranna piranna commented Mar 22, 2016

Pull Request check-list

Please make sure to review and check all of these items:

  • Does make -j8 test (UNIX) or vcbuild test nosign (Windows) pass with
    this change (including linting)?
  • Is the commit message formatted according to [CONTRIBUTING.md][0]?
  • If this change fixes a bug (or a performance problem), is a regression
    test (or a benchmark) included?
  • Is a documentation update included (if this change modifies
    existing APIs, or introduces new ones)?

Affected core subsystem(s)

test, readline, tty

Description of change

Test that characters from stdin are not randomly lost when using a readline.Interface and a tty.ReadStream on process.stdin by writting a text at a slow rate of 60 characters per minute.

When tests are executed without the -j8 flag this test show on stderr the message Assertion failed: (loop->watchers[w->fd] == w), function uv__io_stop, file ../deps/uv/src/unix/core.c, line 864 and exit with a SIGABRT signal. Also, in that case some of the final characters are not received (the faster you write the most you get), probably both problems are related to that previous message.

@mscdex mscdex added readline Issues and PRs related to the built-in readline module. test Issues and PRs related to the tests. labels Mar 22, 2016
@santigimeno
Copy link
Member

@piranna A couple of things I've observed:

  • 60 kpm is very slow for a test. If you increase the rate, does the test still reproduce the error?
  • I've run the test with current master in jessie but it never exits. It seems that the problem is that the parent process never exits.

@santigimeno
Copy link
Member

I meant: is very slow for a test that runs in the parallel folder.

@piranna
Copy link
Contributor Author

piranna commented Mar 22, 2016

60 kpm is very slow for a test. If you increase the rate, does the test still reproduce the error?

There's no problem to increase the speed, in fact it's better. I've put it so slow because I've found a problem where the last characters are lost, and in fact the faster you write the most you receive. Seems it could be related to the assert message, but I was able to write the text as fast as 120kps. What do you suggest to do here?

I've run the test with current master in jessie but it never exits. It seems that the problem is that the parent process never exits.

It needs of pull-request #5776 to work, sorry for not specify it before.

@Trott
Copy link
Member

Trott commented Mar 22, 2016

If you want to submit the test separately from the fix, the test can go in test/known_issues until the fix is landed.

@piranna
Copy link
Contributor Author

piranna commented Mar 22, 2016

Thank for the advice @Trott, I've just done it.

@jbergstroem
Copy link
Member

Perhaps @orangemocha could consider having it part of his PR?

@@ -0,0 +1,73 @@
/**
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you follow the conventions of the other files in this directory (first line is strict mode, second line is a Refs:).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done, I've left the comment with the description of what's trying to check the test (I think it doesn't hurts...).

@orangemocha
Copy link
Contributor

Perhaps @orangemocha could consider having it part of his PR?

The PR for #5574 is ready to go so I'd rather not halt it, but I'll be happy to merge this one once it passes review. Thanks!

@jbergstroem
Copy link
Member

@orangemocha cool, thanks for your feedback!

@piranna
Copy link
Contributor Author

piranna commented Mar 23, 2016

I've just done the fixes suggested by @cjihrig. I think that since #5776 has already landed on master and it was required by this test to pass, maybe It should be moved again to the test folder from the known_issues one, isn't it?

@jbergstroem
Copy link
Member

@piranna yes, I agree. Move it back.

@piranna
Copy link
Contributor Author

piranna commented Mar 23, 2016

@piranna yes, I agree. Move it back.

Done.

Test that characters from stdin are not randomly lost when using a
`readline.Interface` and a `tty.ReadStream` on `process.stdin`
@piranna
Copy link
Contributor Author

piranna commented Mar 24, 2016

I've done a rebase over master since #5776 has been merged but now the test on this pull-request fails:

=== release test-readline-interface-tty-readstream ===                         
Path: parallel/test-readline-interface-tty-readstream
Assertion failed: (loop->watchers[w->fd] == w), function uv__io_stop, file ../deps/uv/src/unix/core.c, line 864.

assert.js:89
  throw new assert.AssertionError({
  ^
AssertionError: 'SIGABRT' === null
    at ChildProcess.<anonymous> (/Users/piranna/github/node/test/parallel/test-readline-interface-tty-readstream.js:57:5)
    at ChildProcess.<anonymous> (/Users/piranna/github/node/test/common.js:385:15)
    at emitTwo (events.js:101:13)
    at ChildProcess.emit (events.js:186:7)
    at maybeClose (internal/child_process.js:850:16)
    at Socket.<anonymous> (internal/child_process.js:323:11)
    at emitOne (events.js:91:13)
    at Socket.emit (events.js:183:7)
    at Pipe._onclose (net.js:477:12)
Command: out/Release/node /Users/piranna/github/node/test/parallel/test-readline-interface-tty-readstream.js

Any clue what could be happening? Maybe some other commit inserted a regression here? Maybe the problem is related with the Assertion failed line? I remember it was being shown before but sudendly it dissapeared until now...

@piranna
Copy link
Contributor Author

piranna commented Mar 24, 2016

Ok, definitely the test is working, but the SIGABRT signal is provocated by the Assertion failed line :-(

@rvagg rvagg force-pushed the master branch 2 times, most recently from c133999 to 83c7a88 Compare October 18, 2016 17:01
@Fishrock123 Fishrock123 added the stream Issues and PRs related to the stream subsystem. label Dec 16, 2016
@Fishrock123
Copy link
Contributor

maybe @nodejs/streams? See @orangemocha's comment above.

@mcollina
Copy link
Member

@Fishrock123 I have not much time to perform a git bisect on this, but if you can point me to some instructions to reproduce the problem, I can look at the issue. Also, knowing which commit fixes the issue would make detecting things more clearly.

Also, what's the status of this one?

@Fishrock123 Fishrock123 added the stalled Issues and PRs that are stalled. label Dec 19, 2016
@Fishrock123
Copy link
Contributor

@mcollina This stalled. I think the included test case should surface the problem, or does it not do that anymore?

@mcollina
Copy link
Member

Should I do anything to run that test? It has been there for minutes, and it is not completing.

@piranna
Copy link
Contributor Author

piranna commented Dec 20, 2016

Should I do anything to run that test? It has been there for minutes, and it is not completing.

Maybe it got stalled waiting to finish, a timeout would be a good idea.

I'm not sure if this problem is still happening, but I suspect it's still the case because there has not be improvements in this area..

@mcollina
Copy link
Member

mcollina commented Dec 20, 2016

On Mac OS X, I just get a stalled process, I can't reproduce the crash. It is not quitting nor erroring on master or node v6.9.2:

$ ./node test/parallel/test-readline-interface-tty-readstream.js

@piranna
Copy link
Contributor Author

piranna commented Dec 22, 2016

I have just found by serendipity when looking for another bug that this one still happens on Linux with Node.js 6.9.2.

@mcollina
Copy link
Member

@piranna I fear it might be partially related to #10214.

@jasnell
Copy link
Member

jasnell commented Mar 1, 2017

ping... is this still necessary / wanted?

@piranna
Copy link
Contributor Author

piranna commented Mar 1, 2017

ping... is this still necessary / wanted?

Yes, it is. In fact, I was checking it just some days ago and the the problem is still there.

@gibfahn
Copy link
Member

gibfahn commented Jun 10, 2017

Okay, so this has been waiting for way too long, let's see if we can get this landed. @piranna I get the same results as @mcollina , the test just hangs.

This PR needs to be rebased on master, and as of #11953, spawnCat is no longer defined. We've also made a bunch of improvements to our test suite, so this should probably be updated to follow the testing guide.

So @piranna do you know why the test is timing out? You can run the test with:

tools/test.py --timeout 5 test/parallel/test-readline-interface-tty-readstream.js

to avoid it hanging forever.

Diff I applied to run the test
diff --git a/test/parallel/test-readline-interface-tty-readstream.js b/test/parallel/test-readline-interface-tty-readstream.js
index 5d0bce8163..1e6652468d 100644
--- a/test/parallel/test-readline-interface-tty-readstream.js
+++ b/test/parallel/test-readline-interface-tty-readstream.js
@@ -1,4 +1,6 @@
 'use strict';
+const common = require('../common');
+
 // Refs: https://github.com/nodejs/node/issues/5574
 
 /**
@@ -6,13 +8,10 @@
  * `readline.Interface` and a `tty.ReadStream` on `process.stdin`
  */
 
-var Interface   = require('readline').Interface;
-var Readable    = require('stream').Readable;
-var ReadStream  = require('tty').ReadStream;
-var spawn       = require('child_process').spawn;
-var strictEqual = require('assert').strictEqual;
-
-var common = require('../common');
+const Interface   = require('readline').Interface;
+const Readable    = require('stream').Readable;
+const ReadStream  = require('tty').ReadStream;
+const spawn       = require('child_process').spawn;
 
 
 const kpm = 60;
@@ -54,10 +53,10 @@ function grandparent() {
   type();
 
   child.on('close', common.mustCall(function(code, signal) {
-    strictEqual(signal, null);
-    strictEqual(code, 0);
+    assert.strictEqual(signal, null);
+    assert.strictEqual(code, 0);
     // cat on windows adds a \r\n at the end.
-    strictEqual(output.trim(), input.trim());
+    assert.strictEqual(output.trim(), input.trim());
   }));
 }
 
@@ -69,5 +68,5 @@ function parent() {
 
   var stdio = [stdin, process.stdout];
 
-  common.spawnCat({ stdio: stdio });
+  spawn('cat', [], { stdio });
 }

@gibfahn gibfahn self-assigned this Jun 10, 2017
/**
* Test that characters from stdin are not randomly lost when using a
* `readline.Interface` and a `tty.ReadStream` on `process.stdin`
*/
Copy link
Member

Choose a reason for hiding this comment

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

Nit: Please use the // style for these kinds of comments, just for consistency

var Readable = require('stream').Readable;
var ReadStream = require('tty').ReadStream;
var spawn = require('child_process').spawn;
var strictEqual = require('assert').strictEqual;
Copy link
Member

Choose a reason for hiding this comment

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

const for each of the above

var spawn = require('child_process').spawn;
var strictEqual = require('assert').strictEqual;

var common = require('../common');
Copy link
Member

Choose a reason for hiding this comment

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

This should be const also, and should be the first import, immediately following the 'use strict' pragma

const input = `1234567890
qwertyuiop
asdfghjklñ
zxcvbnm`;
Copy link
Member

Choose a reason for hiding this comment

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

Would prefer not using a multiline template literal.

var child = spawn(process.execPath, [__filename, 'parent']);
child.stderr.pipe(process.stderr);

var stdin = Readable({read: function() {}});
Copy link
Member

Choose a reason for hiding this comment

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

const stdin = Readable({ read() {} });

@jasnell
Copy link
Member

jasnell commented Aug 24, 2017

One final ping to @piranna ...

@BridgeAR
Copy link
Member

Closing due to a long inactivity. @piranna please a comment if you want to follow up on this and we can reopen this or open a new PR instead.

@BridgeAR BridgeAR closed this Sep 12, 2017
@piranna
Copy link
Contributor Author

piranna commented Sep 12, 2017

I'm too much busy due to work lately, and also found a valid workaround for this, so not sure what to do now... Seems to me problem is that there are several file descriptors for the TTY streams, so if you pause one of them, the others are still open and capable of reading instead of getting blocked.

@BridgeAR
Copy link
Member

@piranna that might be the case. I did not look deeply into this. Do you want to keep on working on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
readline Issues and PRs related to the built-in readline module. stalled Issues and PRs that are stalled. stream Issues and PRs related to the stream subsystem. test Issues and PRs related to the tests.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet