win: gc/test-net-timeout.js failure in v6.2.1 #7291
Comments
mscdex
added
net
|
/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 |
|
Feel free to submit a PR to change it to I'm still not clear if this is a bug in Windows or a bug in Node.js. |
|
@Trott Exactly, I am happy to submit a change to |
|
@nodejs/platform-windows |
|
@gibm Maybe do not use |
|
@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). |
If a test does http.listen(0) or net.listen(0), http.listen(0).address().address returns '::'. Some machines will resolve this to localhost, but not all. Every machine should have localhost defined in /etc/hosts (or equivalent), so it should always resolve. Fixes: nodejs#7291
If a test does http.listen(0) or net.listen(0), http.listen(0).address().address returns '::'. Some machines will resolve this to localhost, but not all. Every machine should have localhost defined in /etc/hosts (or equivalent), so it should always resolve. Fixes: nodejs#7291 PR-URL: nodejs#10854 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michal Zasso <targos@protonmail.com>
If a test does http.listen(0) or net.listen(0), http.listen(0).address().address returns '::'. Some machines will resolve this to localhost, but not all. Every machine should have localhost defined in /etc/hosts (or equivalent), so it should always resolve. Fixes: nodejs#7291 PR-URL: nodejs#10854 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michal Zasso <targos@protonmail.com>
If a test does http.listen(0) or net.listen(0), http.listen(0).address().address returns '::'. Some machines will resolve this to localhost, but not all. Every machine should have localhost defined in /etc/hosts (or equivalent), so it should always resolve. Fixes: nodejs#7291 PR-URL: nodejs#10854 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michal Zasso <targos@protonmail.com>
If a test does http.listen(0) or net.listen(0), http.listen(0).address().address returns '::'. Some machines will resolve this to localhost, but not all. Every machine should have localhost defined in /etc/hosts (or equivalent), so it should always resolve. Fixes: nodejs#7291 PR-URL: nodejs#10854 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michal Zasso <targos@protonmail.com>
If a test does http.listen(0) or net.listen(0), http.listen(0).address().address returns '::'. Some machines will resolve this to localhost, but not all. Every machine should have localhost defined in /etc/hosts (or equivalent), so it should always resolve. Fixes: #7291 PR-URL: #10854 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michal Zasso <targos@protonmail.com>
If a test does http.listen(0) or net.listen(0), http.listen(0).address().address returns '::'. Some machines will resolve this to localhost, but not all. Every machine should have localhost defined in /etc/hosts (or equivalent), so it should always resolve. Fixes: nodejs#7291
If a test does http.listen(0) or net.listen(0), http.listen(0).address().address returns '::'. Some machines will resolve this to localhost, but not all. Every machine should have localhost defined in /etc/hosts (or equivalent), so it should always resolve. Fixes: #7291
If a test does http.listen(0) or net.listen(0), http.listen(0).address().address returns '::'. Some machines will resolve this to localhost, but not all. Every machine should have localhost defined in /etc/hosts (or equivalent), so it should always resolve. Fixes: #7291 PR-URL: #10854 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michal Zasso <targos@protonmail.com>
If a test does http.listen(0) or net.listen(0), http.listen(0).address().address returns '::'. Some machines will resolve this to localhost, but not all. Every machine should have localhost defined in /etc/hosts (or equivalent), so it should always resolve. Fixes: #7291
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.
The text was updated successfully, but these errors were encountered: