Incorrect socket management behavior with .net application

Questions about Wine on Linux
Post Reply
aludom
Newbie
Newbie
Posts: 2
Joined: Fri Mar 22, 2024 2:38 am

Incorrect socket management behavior with .net application

Post by aludom »

I have a .net 3.5 application that runs fine on Windows but have a problem when running on Debian+WINE [wine-4.0 (Debian 4.0-2)].

The problem is a socket binding error "address already in use".

Code: Select all

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)
Unfortunately, when this happens, I can't see the socket on netstat nor in isof.

Furthermore the problem is very strange because it only happens, and it always happen, in the following circumstance (on WINE).
  1. My 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: Select all

	    // 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, but I can't find where.

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
Is this a known WINE bug?
Is there a known problem with freeing sock resources if you create a process startup chain?

Clearly if I simply close the A.exe application and restart it, none of this happens.
aludom
Newbie
Newbie
Posts: 2
Joined: Fri Mar 22, 2024 2:38 am

Re: Incorrect socket management behavior with .net application

Post by aludom »

I add that, if the client connects to the server socket instantiated by A, then the socket is not closed but remains, rightly, in the TIME_WAIT state.

If the socket is in this state when B starts A, the problem does not occur.
  1. LISTEN
  2. TIME_WAIT
  3. TIME_WAIT
  4. LISTEN (when the waiting timeout expires)
Last edited by aludom on Thu Mar 28, 2024 8:30 am, edited 1 time in total.
User avatar
dimesio
Moderator
Moderator
Posts: 13208
Joined: Tue Mar 25, 2008 10:30 pm

Re: Incorrect socket management behavior with .net application

Post by dimesio »

Debian+WINE [wine-4.0 (Debian 4.0-2)].
Wine 4.0 is over 4 years old and no longer supported. The current stable release is 9.0 and the current development release is 9.5. Please retest in a current version.
aludom
Newbie
Newbie
Posts: 2
Joined: Fri Mar 22, 2024 2:38 am

Re: Incorrect socket management behavior with .net application

Post by aludom »

Hi, unfortunately the system runs on an old hardware platform and it is not easy to update the software to the last version.
I wrote here to look for confirmation that this is a wine bug and to find advice on how to work around it.

Also, I haven't found any bugs on Bugzilla related to this scenario, do you have any indication that this issue may have already been fixed?
madewokherd
Level 4
Level 4
Posts: 144
Joined: Mon Jun 02, 2008 5:03 pm

Re: Incorrect socket management behavior with .net application

Post by madewokherd »

Based on Wine Mono test results, it's likely this is still an issue, as various socket tests are flaky. I'd been assuming it was the tests at fault.
Post Reply