Adverse scenario:
- thread “net”
0CConnman::ThreadSocketHandler()
1 CConnman::SocketHandler()
2 CConnman::SocketEvents()
3 CConnman::GenerateSelectSet()
4 Cycles through CConnman::vNodes and remembers some sockets to
5 be polled for readiness later by CConnman::SocketEvents().
6 Lets say socket (file descriptor) 10 is remembered.
- thread “msghand”
0CConnman::ThreadMessageHandler()
1 PeerManagerImpl::ProcessMessages()
2 PeerManagerImpl::ProcessMessage()
3 PeerManagerImpl::PushNodeVersion()
4 CConnman::PushMessage()
5 CConnman::SocketSendData()
6 CNode::CloseSocketDisconnect()
7 Closes socket 10.
- thread “opencon”
0CConnman::ThreadOpenConnections()
1 CConnman::OpenNetworkConnection()
2 CConnman::ConnectNode()
3 CreateSock()
4 Creates a new socket, reusing file descriptor 10.
- thread “net”
0CConnman::ThreadSocketHandler()
1 CConnman::SocketHandler()
2 CConnman::SocketEvents()
3 polls the remembered socket 10, which corresponds to a different
4 connection now (bug)
As a result the following logic may not hold:
I think the severity of this is low and that it has a low chance of happening. However the pattern of “remember a socket by its file descriptor number and use it later, concurrently with other threads that might close it” better be avoided. That pattern could lead to closing or writing to the wrong socket which would be more severe.
