Repository navigation
win: gc/test-net-timeout.js failure in v6.2.1 #7291
Description
Activity
- addednetIssues and PRs related to the net subsystem.Issues and PRs related to the net subsystem.windowsIssues and PRs related to the Windows platform.Issues and PRs related to the Windows platform.testIssues and PRs related to Node.js core tests and test infrastructure.Issues and PRs related to Node.js core tests and test infrastructure.
on Jun 13, 2016 /cc @Trott
Also seems to fail on one of our linux machines:
not ok 5 gc/test-net-timeout # events.js:160 # throw er; // Unhandled 'error' event # ^ # # Error: connect ENETUNREACH :::50340 - Local (:::0) # at Object.exports._errnoException (util.js:1007:11) # at exports._exceptionWithHostPort (util.js:1030:20) # at connect (net.js:874:16) # at net.js:964:9 # at _combinedTickCallback (internal/process/next_tick.js:67:7) # at process._tickCallback (internal/process/next_tick.js:98:9) # at Module.runMain (module.js:577:11) # at run (node.js:340:7) # at startup (node.js:132:9) # at node.js:455:3 # We should do 500 requests --- duration: 0.213s
but that could be a different configuration issue although I think it started around the same timeframe
Not sure if this is a bug in Node.js or if it is a host configuration issue.
For what it's worth, I think it's been suggested that we just get rid of the gc tests, IIRC because they are low-to-zero value and sometimes problematic. Wish I could remember who proposed it so i could @-mention them to make sure I got that right. Maybe it was @bnoordhuis?
/cc @nodejs/build for comments on possibility of a configuration issue vs. bug in Node.js.
Passing
'localhost'to test/gc/test-net-timeout.js#L39 works everywhere, but passing'::'only works on Linux (not on the three windows 7 boxes I tested).Feel free to submit a PR to change it to
'localhost'if you think that's a reasonable workaround.I'm still not clear if this is a bug in Windows or a bug in Node.js.
server.address().addressshould certainly return a usable value, so the test itself should be fine as is.@Trott Exactly, I am happy to submit a change to
'localhost'if that makes sense, but I'd like someone who knows more about this to confirm that this isn't a bug in Windows, it certainly seems problematic.@nodejs/platform-windows
@gibm Maybe do not use
localhost, but instead use the corresponding IPv4/IPv6 address.
This may help in rare cases wherelocalhostcannot be resolved.
I also don't think this is a bug in Windows. From a network perspective it doesn't make sense to connect to "all" interfaces. What if the specified port is available on multiple interfaces? Connect to any interface?if (server.address().family === 'IPv4') { var req = net.connect(server.address().port, '127.0.0.1'); } else { var req = net.connect(server.address().port, '::1'); }@quaidn that does make sense, and I'll try it to make sure that works, but I wonder whether this code should be (or already is) somewhere else in node (for example in common.js).
- added a commit that references this issue
on Jan 17, 2017 - added a commit that references this issue
on Mar 8, 2017 - added a commit that references this issue
on Mar 8, 2017 - added a commit that references this issue
on Jul 27, 2026
The problem seems to be due to this change, specifically the use of
server.address().address. Changing the address back to'127.0.0.1'makes the test pass.From what I can work out, the address defaults to :: (the equivalent of 0.0.0.0) for IPv6 enabled machines. It seems that it never gets resolved to ::1 (localhost) on windows. The same test passes on Linux.