From 0ce848af1ab539ac86831f40156ebc59ccc7a3b6 Mon Sep 17 00:00:00 2001 From: Gireesh Punathil Date: Thu, 26 Nov 2015 07:27:18 -0500 Subject: [PATCH] test: share maxBuffer between stdout and stderr The test case assumes that child's stdout should be holding the data as prescribed by the child's codeflow. However, as the child code runs asynchronously, this order can be reversed. Assertion fails when console.error() was first processed in the child. While the call was made in order, their fd's became IO ready in the reverse order. Consequently, stderr populated its data into the channel buffer, and crossed the maxBuffer and caused the child termination, short-circuiting stdout's event. While this is not happening in Linux or Windows, no documentated evidence exists for the order of event rediness in the event loop. The test should not assume that buffer is consumed first by stdout. --- test/parallel/test-child-process-spawnsync-input.js | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/test/parallel/test-child-process-spawnsync-input.js b/test/parallel/test-child-process-spawnsync-input.js index f043d0c5e355f1..fb7d8fe424e98b 100644 --- a/test/parallel/test-child-process-spawnsync-input.js +++ b/test/parallel/test-child-process-spawnsync-input.js @@ -95,4 +95,11 @@ assert.ok(ret.error, 'maxBuffer should error'); assert.strictEqual(ret.error.errno, 'ENOBUFS'); // we can have buffers larger than maxBuffer because underneath we alloc 64k // that matches our read sizes -assert.deepEqual(ret.stdout, msgOutBuf); + +// While we are writing to stdout first which is expected to +// overflow the buffer and cause child to return, the actual +// write order can be reversed based on how uv loop get them. +// So expect either stdout or stderr to be holding the data +assert.ok(ret.stdout.toString() === msgOutBuf.toString() || + ret.stderr.toString() === msgErrBuf.toString(), + 'expected at least one stream to write back.');