Bug: `Server.listen()` hangs with no error when listening on in-use port

[lobsterkatie]

• Version: v10.18.1
• Platform: Darwin Katies-MacBook-Pro.local 19.6.0 Darwin Kernel Version 19.6.0: Mon Aug 31 22:12:52 PDT 2020; root:xnu-6153.141.2~1/RELEASE_X86_64 x86_64
• Subsystem: net.js

What steps will reproduce the bug?

1. Run a server (any server) on some port (in my case, 3000).
2. Call http.createServer to get a Server object, and then call .listen(<your-already-occupied-port>) on it

How often does it reproduce? Is there a required condition?

You must have another server already running on the port in question.

What is the expected behavior?

I'd expect that if I try to listen on a port which is already in use, I'd get an error.

What do you see instead?

My script just hangs.

Additional information

The script I'm trying to run is this one: https://github.com/getsentry/sentry-javascript/blob/c864ff63d3515be4efa3b1399ef9cafe89497661/packages/node/test/manual/express-scope-separation/start.js

Perhaps I'm missing something - I'm relatively new to the node ecosystem - but I've used a debugger to step into first the express and then the node listen methods, and nowhere do I see a check for an in-use port, nor any kind of error or warning.

Feel free to point me in the right direction if this is not, in fact, a bug.

Thanks!

[mmomtchev]

@lobsterkatie, I suggest you take your issue to expressjs.com since this is what you are using to bind your server. Binding to a port, on every OS, is done through a bind call and the OS will return EADDRINUSE error if another process is already listening. If you want to check if node is indeed making this bind syscall on behalf of express than you can do the following:

cp /usr/local/bin/node .    # make a local copy of node
codesign --remove-signature node    # remove the SIP protection (alternatively you can boot in safe mode and disable it once for all with csrutil, but I don't recommend it)
sudo dtruss -t bind ./node test.js # will display all bind syscalls of node

[Ayzrian]

FWIW, @lobsterkatie have you subscribed to the 'error' event of the server?
I mean if you have not subscribed to that event the emitted error will be thrown and cause the crash of your program.

[lobsterkatie]

Thanks to both. I'll look into both of those and let you know if I have any more questions. I think this can be closed now.

Cheers!

[crisdosaygo]

Unfortunately I can reproduce this issue with Node on Windows.