When binding server to a UNIX socket in an abstract namespace, the address length is wrong

[yseymour]

Version

20.10.0

Platform

Linux debian 6.1.0-10-arm64 #1 SMP Debian 6.1.37-1 (2023-07-03) aarch64 GNU/Linux

Subsystem

No response

What steps will reproduce the bug?

new http.Server().listen("\0foo")

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

Every time

What is the expected behavior? Why is that the expected behavior?

The server binds to a socket that lsof -U renders as @foo. Other processes can connect to that socket.

What do you see instead?

The server binds to a socket that lsof -U renders as @foo@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

It looks like the address length is not set correctly.

I tried binding a C++ program to an abstract socket (using ZeroMQ) and lsof rendered that one as I'd expect (not padded), so this isn't some quirk of lsof, as far as I know.

Additional information

I don't see any reference to abstract namespaces in the documentation, so I'm not sure if this is officially supported. However, I note PR #49667, which appears to be about fixing this, and which introduces a test that binds using the same address syntax (a null byte followed by a name). AFAICT that landed in 20.8.0, so I was hoping this would work.

(That test connects to the socket using http.get, and I can do the same thing locally and it works... but the fact that lsof renders the address that way seems like there is a bug somewhere...)

[santigimeno]

This has been fixed in libuv by libuv/libuv@1dd0ab1.

[santigimeno]

Fixed in 36dcd39