[Bug 53588] New: listening tcp socket is removed after some time
https://bugs.winehq.org/show_bug.cgi?id=53588 Bug ID: 53588 Summary: listening tcp socket is removed after some time Product: Wine Version: 3.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: winsock Assignee: wine-bugs(a)winehq.org Reporter: marcsamuro(a)gmail.com Distribution: --- Hi, i'm testing a rather simple background windows application that uses only disk, network, memory, processes and threads. When starting, the application opens a pair (ip4 & ip6) of listening socket on TCP port 80, and another pair of listening sockets on UDP port 13000. They are always kept open. At first everything works fine, all listening ports appear when doing netstat and the application works great : netstat -nap Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 15897/wineserver64 tcp6 0 0 :::80 :::* LISTEN 15897/wineserver64 udp 0 0 0.0.0.0:13000 0.0.0.0:* 15897/wineserver64 udp6 0 0 :::13000 :::* 15897/wineserver64 However, after some time (a few hours ?) suddenly the tcp listening sockets do no longer appear when doing netstat : netstat -nap Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name udp 0 0 0.0.0.0:13000 0.0.0.0:* 15897/wineserver64 udp6 0 0 :::13000 :::* 15897/wineserver64 The UDP listening socket still appear, and the application responds fine to requests on the UDP port. However the TCP (http) connection on port 80 does not respond anymore. What could be the cause of that, what can i test to pinpoint the problem ? I saw the sockets are owned by wineserver64 so i guess they are managed by wine. Why does only the TCP disappear and not the UDP ? Is there a timeout or some other settings ? On pure Windows, the application works fine since years, so it must be some problem with linux or wine. I'm using wine-3.0 (Ubuntu 3.0-1ubuntu1) i'm starting the app with the command line : nohup wine planet_server.exe & Thank you. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53588 marc samuro <marcsamuro(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|3.0 |7.0 --- Comment #1 from marc samuro <marcsamuro(a)gmail.com> --- i'm doing test with wine-7.0 now, and found a clue: tcp sockets are owned by wineserver, whereas udp sockets are owned by the windows app. That explains the difference, but why does wineserver drop them ? $ netstat -nap Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 28183/wineserver tcp6 0 0 :::80 :::* LISTEN 28183/wineserver udp 0 0 0.0.0.0:13000 0.0.0.0:* 28181/planet_server udp6 0 0 :::13000 :::* 28181/planet_server -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53588 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|major |minor CC| |z.figura12(a)gmail.com --- Comment #2 from Zeb Figura <z.figura12(a)gmail.com> --- I don't know how netstat is determining who "owns" the sockets, but that difference doesn't make much sense. Wine sockets are created in the wineserver process but then shared with the client, so both processes should end up holding an fd to the same socket at any given point. I also don't have any idea why the TCP sockets would cease to respond after a while. Is it possible to share the program itself, or link to a free download? Or, failing that, can you try to get a +server,+timestamp log? If it takes hours to reproduce it may become prohibitively large, though... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53588 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|minor |normal -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53588 --- Comment #3 from marc samuro <marcsamuro(a)gmail.com> --- ok i'm back. I've been running two occurences of the server since 3 weeks now with wine-7.0 and I almost hoped the problem would disappear, but it's back :( One of my two servers is still fine, the other does not respond anymore on port 80 (but works fine on the other tdp port so i know the process is alive and well). And when looking with netstat -an the tcp listener on port 80 just disappeared. I'm running at least 10 of these servers on pure Windows servers since years so i can eliminate a problem with the Windows software itself. It can only be Wine suddenly closing (or removing ?) the tcp listener. This is for me a blocking issue, i cannot move from Windows to Unix servers if suddenly the website stops responding. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53588 --- Comment #4 from marc samuro <marcsamuro(a)gmail.com> --- ok i think now we're getting somewhere, i have additional log info. the application does these 3 calls when accepting a tcp call : s = accept (listener setsockopt (s, WSAEventSelect (s, and one of these 3 seems to return WSAENOTCONN 10057 to signal that the connection is already closed. It seems that in Windows these 3 calls never fail. Windows probably does not test this early that the connection is down. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53588 --- Comment #5 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to marc samuro from comment #4)
ok i think now we're getting somewhere, i have additional log info.
the application does these 3 calls when accepting a tcp call :
s = accept (listener setsockopt (s, WSAEventSelect (s,
and one of these 3 seems to return WSAENOTCONN 10057 to signal that the connection is already closed.
It seems that in Windows these 3 calls never fail. Windows probably does not test this early that the connection is down.
You don't have any idea which call is failing, though? Are the return values being tested, or just WSAGetLastError()? Which socket option is being set? We should never end up returning WSAENOTCONN from WSAEventSelect(), but we might propagate an ENOTCONN from the host for accept() or setsockopt(). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla