Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate flaky parallel/test-debug-port-numbers #7034

Closed
Trott opened this issue May 28, 2016 · 1 comment
Closed

Investigate flaky parallel/test-debug-port-numbers #7034

Trott opened this issue May 28, 2016 · 1 comment
Labels
test Issues and PRs related to the tests.

Comments

@Trott
Copy link
Member

Trott commented May 28, 2016

This appears to be the (or one) cause of the recent firestorm of EADDRINUSE failures on CI. (@jbergstroem reported that the test was running and not exiting on CI hosts exhibiting the EADDRINUSE issue.)

Ran a stress test to confirm, and sure enough...

https://ci.nodejs.org/job/node-stress-single-test/nodes=freebsd102-64/748/console

+ OK=5
+ echo '5   OK: 5   NOT OK: 0   TOTAL: 999'
5   OK: 5   NOT OK: 0   TOTAL: 999
+ for i in '`seq $RUN_TIMES`'
+ python tools/test.py -p tap --mode=release parallel/test-debug-port-numbers
1..1
ok 1 parallel/test-debug-port-numbers
  ---
  duration_ms: 1.376
  ...
+ OK=6
+ echo '6   OK: 6   NOT OK: 0   TOTAL: 999'
6   OK: 6   NOT OK: 0   TOTAL: 999
+ for i in '`seq $RUN_TIMES`'
+ python tools/test.py -p tap --mode=release parallel/test-debug-port-numbers
1..1
not ok 1 parallel/test-debug-port-numbers
# TIMEOUT
# debug> debug> debug> debug> �< Debugger listening on port 12346�< Debugger listening on port 12347
# debug> �connecting to 127.0.0.1:12347 ...
# ��debug> < Debugger listening on port 12348< Error: listen EADDRINUSE :::12349�connecting to 127.0.0.1:12346 ...
# debug> �connecting to 127.0.0.1:12348 ..
# debug> �connecting to 127.0.0.1:12349 .... ok
# debug>  ok
# debug>  ok
# debug> �<     at Object.exports._errnoException (util.js:1007:11)
# <     at exports._exceptionWithHostPort (util.js:1030:20)
# <     at Agent.Server._listen2 (net.js:1253:14)
# <     at listen (net.js:1289:10)
# <     at Agent.Server.listen (net.js:1385:5)
# <     at Object.start (_debug_agent.js:21:9)
# <     at startup (node.js:74:44)
# <     at node.js:444:3
# debug>  ok
# debug> �break in test/parallel/test-debug-port-numbers.js:1
# �> 1 'use strict';
# �  2 
# �  3 const common = require('../common');
# debug> �break in test/parallel/test-debug-port-numbers.js:1
# �> 1 'use strict';
# �  2 
# �  3 const common = require('../common');
# debug> �break in test/parallel/test-debug-port-numbers.js:1
# �> 1 'use strict';
# �  2 
# �  3 const common = require('../common');
# debug> 
  ---
  duration_ms: 60.65
  ...
+ NOK=1
+ echo '7   OK: 6   NOT OK: 1   TOTAL: 999'
7   OK: 6   NOT OK: 1   TOTAL: 999
+ for i in '`seq $RUN_TIMES`'
+ python tools/test.py -p tap --mode=release parallel/test-debug-port-numbers
1..1
not ok 1 parallel/test-debug-port-numbers
# TIMEOUT
# debug> debug> debug> debug> ��< Error: listen EADDRINUSE :::12349
# < Debugger listening on port 12347debug> �connecting to 127.0.0.1:12349 ..
# .�< Debugger listening on port 12346
# debug> �connecting to 127.0.0.1:12347 ...��< Debugger listening on port 12348<     at Object.exports._errnoException (util.js:1007:11)
# <     at exports._exceptionWithHostPort (util.js:1030:20)
# <     at Agent.Server._listen2 (net.js:1253:14)
# <     at listen (net.js:1289:10)
# <     at Agent.Server.listen (net.js:1385:5)
# <     at Object.start (_debug_agent.js:21:9)
# <     at startup (node.js:74:44)
# <     at node.js:444:3
# 
# debug> debug> �connecting to 127.0.0.1:12348 ..debug>  ok
# . ok
# debug> debug> �connecting to 127.0.0.1:12346 ... ok
# debug>  ok
# debug> �break in test/parallel/test-debug-port-numbers.js:1
# �> 1 'use strict';
# �  2 
# �  3 const common = require('../common');
# debug> �break in test/parallel/test-debug-port-numbers.js:1
# �> 1 'use strict';
# �  2 
# �  3 const common = require('../common');
# debug> �break in test/parallel/test-debug-port-numbers.js:1
# �> 1 'use strict';
# �  2 
# �  3 const common = require('../common');
# debug> 

The commit that landed this test is dated October, but it only landed two days ago.

/cc @bnoordhuis

@Trott Trott added debugger test Issues and PRs related to the tests. labels May 28, 2016
@bnoordhuis
Copy link
Member

I can reproduce and I figured it out, see #7037 for a workaround.

The problem is that the debugger process spawns the debuggee (a.k.a. the inferior) but doesn't always terminate it on exit. If you modify the test to send a SIGKILL to the debugger, the test always fails on the second run, because the inferior stays around, hogging the port.

bnoordhuis added a commit that referenced this issue May 28, 2016
On UNIX platforms, the debugger doesn't reliably kill the inferior when
killed by a signal.  Work around that by spawning the debugger in its
own process group and killing the process group instead of just the
debugger process.

This is a hack to get the continuous integration back to green, it
doesn't address the underlying issue, which is that the debugger
shouldn't leave stray processes behind.

Fixes: #7034
PR-URL: #7037
Refs: #3470
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Fishrock123 pushed a commit to Fishrock123/node that referenced this issue May 30, 2016
On UNIX platforms, the debugger doesn't reliably kill the inferior when
killed by a signal.  Work around that by spawning the debugger in its
own process group and killing the process group instead of just the
debugger process.

This is a hack to get the continuous integration back to green, it
doesn't address the underlying issue, which is that the debugger
shouldn't leave stray processes behind.

Fixes: nodejs#7034
PR-URL: nodejs#7037
Refs: nodejs#3470
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
rvagg pushed a commit that referenced this issue Jun 2, 2016
On UNIX platforms, the debugger doesn't reliably kill the inferior when
killed by a signal.  Work around that by spawning the debugger in its
own process group and killing the process group instead of just the
debugger process.

This is a hack to get the continuous integration back to green, it
doesn't address the underlying issue, which is that the debugger
shouldn't leave stray processes behind.

Fixes: #7034
PR-URL: #7037
Refs: #3470
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
MylesBorins pushed a commit that referenced this issue Jun 29, 2016
On UNIX platforms, the debugger doesn't reliably kill the inferior when
killed by a signal.  Work around that by spawning the debugger in its
own process group and killing the process group instead of just the
debugger process.

This is a hack to get the continuous integration back to green, it
doesn't address the underlying issue, which is that the debugger
shouldn't leave stray processes behind.

Fixes: #7034
PR-URL: #7037
Refs: #3470
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
MylesBorins pushed a commit that referenced this issue Jul 12, 2016
On UNIX platforms, the debugger doesn't reliably kill the inferior when
killed by a signal.  Work around that by spawning the debugger in its
own process group and killing the process group instead of just the
debugger process.

This is a hack to get the continuous integration back to green, it
doesn't address the underlying issue, which is that the debugger
shouldn't leave stray processes behind.

Fixes: #7034
PR-URL: #7037
Refs: #3470
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
test Issues and PRs related to the tests.
Projects
None yet
Development

No branches or pull requests

2 participants