Strange behavior specific to Windows 2012r2 with a single processor

[Trott]

This came up during many attempts at addressing flakiness in test-net-error-twice.js. The flakiness is resolved now, but the underlying issue remains. Not entirely sure this is a bug but it's strange enough I think to warrant an explanation. (And it's probably a bug.)

This has been observed only on systems that meet the following criteria:

• Windows 2012r2
• single processor

The following code will throw an AssertionError because the error callback is never triggered. If you comment out the useless assignment of console to foo, though, then the code works. If you uncomment the console.log() in the connection callback (or otherwise put a console.log() in one of many but not all places in the file), then the code works.

Why is this? Windows bug? libuv bug? Not a bug at all? (OK, if that's the case, then fine, it's not a bug, but seriously, why does this happen? Why should assigning console to a variable affect this at all?)

'use strict';
var foo = console; // Comment out this line and the callback fires as expected.
const assert = require('assert');
const net = require('net');

const buf = new Buffer(10 * 1024 * 1024).fill(0x62);

var errorTriggered = false;

const srv = net.createServer( (conn) => {
//  console.log('foo'); // Uncomment this line and the callback fires as expected.
  conn.write(buf);
  conn.on('error', () => { errorTriggered = true; }); // This callback isn't firing.
  conn.on('close', () => { srv.unref(); });
}).listen(12346, () => {
  const client = net.connect({ port: 12346 });
  client.on('connect', () => { client.destroy(); });
});

process.on('exit', () => {
  // Check that the callback fired.
  assert(errorTriggered);
});

Tagging everyone that has been involved in previous issues where this has caused problems because they might have more insight to add here: @joaocgreis @bnoordhuis @mscdex @bengl

Ref: #4062

[davidvgalbraith]

cf. #4291 for another situation where a seemingly-innocuous reference to a stream has some unanticipated side effects (i.e. you can replace the process.stdout; in that ticket with var foo = console; and it'll trigger the segfault).

[Trott]

@nodejs/platform-windows I don't suppose anyone can easily test to see if this is still an issue in 6.2.2 or not? (I'm unaware of anything specific that would fix it, but this issue has been dormant for over six months so who knows?)

If it is fixed, I'd be interested to know what version fixed it.

[bnoordhuis]

@Trott Can this be closed?

[Trott]

@bnoordhuis asked:

@Trott Can this be closed?

TL;DR: Closing.

I don't think we run Windows 2012R2 in CI anymore so I don't have a way to even test this anymore. I'm OK with closing it. If someone else is still experiencing this and wants to raise the issue, they can comment here or open a new issue referencing this one.

[bzoz]

This was fixed by libuv update to 1.10 in #9267.

This still happens with v6.10. But, v6.x-staging uses new libuv, so it will be fixed there.

[MylesBorins]

v6.11.0 came out today with the new libuv!

[bzoz]

Yep, this does not reproduce with v6.11.0