https://bugs.winehq.org/show_bug.cgi?id=56488
Bug ID: 56488 Summary: TCP socket appears to be in use but it is not Product: Wine Version: 4.0-rc2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: bugzilla400@gmail.com Distribution: ---
I have a .net 3.5 application that runs fine on Windows but have a problem when running on Debian.
The problem is a socket binding error "address already in use". CODE: System.Net.Sockets.SocketException: Unknown error (0x2740) at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress) at System.Net.Sockets.Socket.Bind(EndPoint localEP)
netstat and lsof commands don't show the socket that appears to be in use, so I assume it's not really in use.
Furthermore the problem only happens, and it always happen, in the following circumstance. 1. The program A.exe listens successfully on the server socket <anyip>:<port>. 2. Then it start the program B.exe and close itself (closing the socket too). 3. Program B.exe do something and then starts again A.exe. 4. A.exe try to bind the server socket but in that case it fails with the error "address already in use". 5. Restart A.exe, now the binding success.
To start the new process I'm using System.Diagnostic.Process. CODE:
// This is only a generic example var process = new Process() { StartInfo = new ProcessStartInfo { FileName = "cmd", Arguments = "/c /usr/bin/bash -c "/usr/bin/sleep 5 && /usr/bin/wine path/of/process/program.exe"", UseShellExecute = false, WorkingDirectory = "the/working/dir", } }
These are the socket states after each steps (netstat): 1. LISTEN 2. not listed due to socket is closed 3. not listed due to socket is closed 4. not listed due to socket is closed <- But I have got the error 5. LISTEN
I suppose that the A and B processes close properly because I don't see them in htop anymore. There seems to be something left hanging.
I've found that if I don't relaunch A.exe from B, but do it manually, everything works fine.
I also noticed this behavior that I wasn't expecting: - if I use socket.Accept the socket is bound to the A.exe process, - if I use socket.BeginAccept the socket is bound to the winserver32 process
Clearly if I simply close the A.exe application and restart it all works fine.
https://bugs.winehq.org/show_bug.cgi?id=56488
--- Comment #1 from bugzilla400@gmail.com --- I found that if a client connects to the server socket instantiated by A, then the socket is not closed but remains, rightly, in TIME_WAIT state.
If the socket is in this state when B starts A, then the problem does not arise.