This is Windows specific and I don't know if it's reproducible outside of Windows-to-Windows UDP communication.
When a UDP packet is sent to a Windows machine and nothing is waiting data on that port, Windows replies with an ICMP packet of (not verified) "Destination port unreachable" (firewall must be disabled, otherwise the ICMP packet is produced and then discarded by default firewall rules).
When performing a WSARecvFrom on a UDP socket, Windows reports a WSAECONNRESET error if such an ICMP packet was received because of a previous WSASendTo with the same address:port combination.
Due to the nature of UDP, and contrary to what the WSARecvFrom documentation seems to imply, a UDP socket is perfectly recoverable and usable after a WSAECONNRESET error (and, I assume, WSAENETRESET); after all the UDP socket can potentially be used to receive-from other hosts/ports and the socket carries no relevant state.
With GSocket, there is a caveat, however. The condition mask has the FD_READ bit set after a UDP socket fails with WSAECONNRESET, even if no data is available on the socket; this causes further select calls (after the error) to report the socket as readable when, in fact, it's not.
This change resets the FD_READ flag on a socket when caused the above error conditions; there's no 'if' to filter between datagram and stream sockets as the change should be harmless in the case of stream sockets which are, however, very unlikely to be usable after a WSAECONNRESET.