http://bugs.winehq.com/show_bug.cgi?id=949
Summary: shutdown() never does anything for overlapped sockets Product: Wine Version: CVS Platform: PC URL: http://www.proxomitron.org/ OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-net AssignedTo: wine-bugs@winehq.com ReportedBy: prupe@myrealbox.com
A problem appeared with version 4.3 of Proxomitron (http://www.proxomitron.org/), a local web filtering proxy. The client (the web browser, Opera 6.02/Linux in this case) never sees the connection close, despite the fact that the proxy does indeed call closesocket. So the browser keeps waiting for more data until the user aborts. I've verified this with "telnet localhost 8080".
The relevant section of the log with -debugmsg +winsock is trace:winsock:WS_shutdown socket 0058, how 1 3 1 trace:winsock:WS2_register_async_shutdown s 88 fd 16 type 2 trace:winsock:WSACreateEvent trace:winsock:WS2_make_async wsa 0x4026bf08 trace:winsock:WS2_make_async wsa 0x4026bf08, ops 0x408858f8, h 88, ev 72, fd 16, func 0x40878db4, ov 0x4026be98, uov 0x4026be98, cfunc (nil) trace:winsock:WS_closesocket socket 00000058 Proxomitron 4.2, which works fine, does only trace:winsock:WS_closesocket socket 00000058 In both cases, socket 0058 is the connection between the web browser and the proxy.
I've traced this behavior to WS_shutdown, dlls/winsock/socket.c. When the socket is overlapped, WS_shutdown does things differently. Rather than shut down the connection right away, it registers a function to be called... well, that's the thing, I don't know when it will be called. In this case there are no other outstanding overlapped I/O requests for that socket (in fact, this app never uses overlapped I/O, the attribute just happens to be on by default), and the other end of the socket (the browser) will never send anything because it's waiting for read/close events. So what is supposed to trigger the call to WS2_async_shutdown?
Removing the "if (flags & FD_FLAG_OVERLAPPED)" branch fixes the problem, but is incorrect according to the check-in comment for v1.92 of socket.c.
Possible solutions: (1) Make sure closesocket cancels the overlapped shutdown request if called before the shutdown occurs. However, this is just hiding the problem since shutdown is still effectively a no-op. On the other hand, shouldn't closesocket cancel any pending requests anyway? (2) In WS_shutdown, don't do the special async stuff unless there is actually a pending overlapped read or write on that socket. (3) More generally, don't do any special processing for an overlapped socket until the app actually uses that capability. In other words, a socket isn't really considered overlapped until the app calls WSARecvFrom, etc. with a real OVERLAPPED structure.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://bugs.winehq.com/show_bug.cgi?id=949. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.