WebSocketServer stops running after a while. getsockname failed after a successful accept().

[geneotech]

Hello! I'm using WebSocketServer.cpp to implement a simple signalling server (running on Ubuntu 22.04) for my WebRTC-based game. Eventually, I always end up getting a fatal error on a call to ::getpeername right after accept()ing a new connection. It causes the server to shutdown and stop accepting new connections:

	if (::getpeername(mSock, reinterpret_cast<struct sockaddr *>(&addr), &addrlen) < 0)
		throw std::runtime_error("getsockname failed");

This is strange given that accept() should return a connected socket, and the previous calls to ::ioctlsocket and ::setsockopt succeed.

Verbose logs:

(nothing for ~14 minutes)
[02:15:53] rtc::impl::TcpTransport::TcpTransport@63: Initializing TCP transport with socket
[02:15:53] rtc::impl::WebSocketServer::runLoop@94: WebSocketServer: getsockname failed
[02:15:53] rtc::impl::WebSocketServer::runLoop@97: Stopped WebSocketServer
(nothing later)

(The last successful connection before that was 14 minutes ago)

This is usually after my signalling server works perfectly for a day or two having handled tens, hundreds of connections prior.
It's likely not a resource leak on my part since the logs show an exactly matching number of:

rtc::impl::WebSocket::WebSocket@41: Creating WebSocket

and:

rtc::impl::WebSocket::~WebSocket@65: Destroying WebSocket

Could this be a threading issue? I see that ::accept and the corresponding closesocket within TcpTransport are under different mutexes (first under mSockMutex and the latter under mSendMutex). I saw a similar issue here:
grpc/grpc#35076 (comment)

[paullouisageneau]

Thank you for reporting. I don't think this is a threading issue as getpeernameis called immediately and only the server thread manipulates the new incoming socket. It's possible that the socket is immediately closed.

The main issue is that such an error with an incoming connection should not make the whole server fail, it should be caught earlier.

[paullouisageneau]

It should be fixed by #1175