REPL sometimes prints no output on Windows

[seishun]

• Version: v6.3.0 and master
• Platform: Windows 10 64-bit
• Subsystem: repl

REPL randomly prints no output when evaluating an expression.

[joaocgreis]

Bisected, this was caused by da8e510

This does not reproduce in Windows 2008, but does in Windows 2012.

cc @addaleax

[addaleax]

I’ve been trying some stuff in a VM, can either of you confirm that commenting out both _setRawMode() lines from da8e510 “fixes” the behaviour?

[joaocgreis]

@addaleax I can confirm that. Deleting those lines fixed the problem.

I wonder if libuv/libuv#866 makes any difference here, this might be some race condition due to the succession of enter keypresses. (Not related to speed though, this happens both when typing fast and slow.)

[addaleax]

@joaocgreis Sorry, my access to practical Windows testing (and knowledge of how the Windows console works) is quite limited… that surely seems like something that could be related to me.

Do you think you (or @nodejs/platform-windows in general?) could look at what’s causing this? If not, I think disabling the Ctrl+C feature for Windows might be a good idea for now, that’s certainly less important than working REPL output.

[BurtHarris]

I'm seeing REPL weirdness on Windows 10 (64-bit), could this be related?

C:\my\typeshell>node
> var a=[1,2,3]
undefined
> var b=[a]
undefined
> a
[ 1, 2, 3 ]
> b
1, 2, 3 ] ]            <--- Note missing leading brackets
>
C:\my\typeshell>node --version
v6.3.1

Note: explicitly calling console.log() rather than simply evaluating expressions results in normal-looking output.

[BurtHarris]

Seems like a timing issue related to the escape sequences readline.js is using to manipulate cursor position. One some occasions I see missing output on a line below the active prompt.

This is a tough bug, as doesn't reproduce while single-stepping under the debugger even though I have a generally reproducible test case.

It also looks like libuv/libuv#889 implements a change under Windows 10 which uses the new Windows-native escape sequence support, rather than emulating VT-100 in libuv!

[BurtHarris]

OK, I finally caught this in the debugger by placing a breakpoint on the call to self.displayPrompt(); in function finish(). Somehow, the output from the command is split into two lines, and displaying the prompt is overwriting the missing output. The strange thing is that the two lines seem to be out-of-order: e.g the cursor is on the first opening bracket on bottom line below just before the prompt is displayed:

> b
[ [ 1, 3, 2 ] ]
>
> b
1, 3, 2 ] ]
[ [

I don't fully understand how the output line is getting split like this, but I'm guessing it has something to do with _setRawMode() and the timing of echoing the newline. Hope that helps @addaleax, is there a way for me to comment this out without rebuilding Node?

[addaleax]

@BurtHarris Thanks for taking a look at this! What you’re saying makes sense, but I don’t know where this line splitting could possibly come from, either.

is there a way for me to comment this out without rebuilding Node?

I wish there were… I mean, I guess you can try overriding readline.Interface.prototype._setRawMode manually by passing a --require argument to node, but for “real” changes to the code, Node probably has to be rebuilt.

[joaocgreis]

I've been looking into this, but so far haven't been able to make much progress. Windows 7 does not reproduce this bug, so this might be caused by the same changes in Windows console that motivated libuv/libuv#866 , but I haven't been able to pinpoint the problem yet.

@addaleax since this is not likely to be an easy fix, can you disable the Ctrl-C feature for Windows for now?