Hi,
I will now start to submit a new series of patches for Winsock2-related issues. Most of it is for overlapped IO, but there are some other issues, too.
I have done a fair bit of testing with 16 and 32 bit network-oriented Windows apps, and found no regressions (well some apps wouldn't install or run with either the CVS version or my patched version of wine).
Among the tested apps are - Opera (v5.12, 32bit, and 3.62, 16bit) - FreeAgent (news reader, 16bit) - Solstice Internet Mail (16bit) - Hamster local news server (32bit, interesting because it's using ReadFile()/WriteFile() for overlapped socket IO) - My evil overlapped testing server/client app
I spotted a number of bugs with the "big" patch I sent to wine-devel last Friday. These are fixed in the version I'll submit now.
The patch is now split into parts again (one bug fix for an earlier patch of mine that is already in CVS, and 7 "real" parts).
Most of the testing has of course been done with the full patch set applied. I have tried to separate logically independent units, but I cannot swear that all is fine if only part of them is applied, and the later patches do fix some important problems. The main reason for splitting the stuff up is to make it easier for people to review.
I honestly think that these patches are now ready for being applied to CVS and tested in the field.
Here is the overall patch summary (for detailed explanantions see the patches thenmselves):
- Correct handling of deferred WSAAccept() operations, - Change register_async() and the queue_async() method to allow more flexibility, needed for sockets, - Server support for overlapped IO on sockets, - Fix problem with FD_CLOSE never being delivered in some situations, - Wait for POLLIN if FD_CLOSE event notification is requested to catch grateful close or shutdown by the peer (empty recv(), no POLLHUP), - Implement overlapped WSARecvFrom()/WSASendTo() and WSAGetOverlappedResult(), - Change shutdown() to account for pending overlapped requests, - Change ReadFile() semantics for overlapped reads on sockets (return even if buffer is not yet full), - Improve error reporting for asynchronous requests (files and sockets) - Account for the SO_OPENTYPE socket option on a per-thread basis.
I plan to look into the regression-testing code and also supply a few tests for the new socket functionality.
Cheers (and please test this stuff with your apps!), Martin
Hello Martin.
I tested your new series of patches with aol7 and I get a crash. Attached is the output of aol7 with the segfault caused by the last series of patches.
The wine debugger comes up and says " Unhandled exception: page fault on read access to 0x00000000 in 32bit code...
FILE_GetUnixHandleType+0x4c [file.c: 346] in libntdll.dll.so 346 if (((access & GENERIC_READ) && (*flags & FD_FLAG_RECV_SHUTDOWN) ) ||"
I've been working on trying to figure out why aol7 doesn't work under wine for a few weeks, but I was using the old code up until now. Actually, with the current wine tree, you can launch aol and login, but you can't get any web content or your buddy list. I think that both of these operations go through aol's web proxies and require a successful handshake with the proxy to succeed.
Getting aol to run under wine is a major priority for us here at Lindows because of 1.) the sheer size of the installed base of aol users, which is in the tens of millions, and 2.) the fact that for people who rely on aol for internet access, linux is basically useless.
Basically, what I know is that aol7 uses asynchronous sockets, but doesn't seem to use overlapped io, unless you're on a modem. When aol is trying to connect to it's web proxy it only sends one packet out when running under wine, and then after a while gets an ACK packet in response from the proxy. The one packet that gets sent is completely identical to the one sent under windows. Under windows, it actually sends out three packets in rapid succession, and then gets a response from the proxy. The packets sent are using the AIM protocol and can be examined using ethereal under windows and under linux. The handshake between the aol client and the proxy is as follows:
client -> AIM packet, family: 0x5472 client -> AIM packet, family: 0x5472 client -> AIM packet, family: 0x7963 proxy -> AIM packet, family: 0x7963
I looked at the return code from ws2_32.send and it claims that the requested number of bytes were sent successfully. Also, there are no obvious errors around the time that the handshake packets are sent. I can send the output of +winsock once I get this new seg fault resolved.
I have to thank you for the amazing work you're doing on sockets and overlapped IO, and for any help you would be so generous as to offer me.
Thanks michael
On Tuesday 23 April 2002 01:39 pm, Martin Wilck wrote:
Hi,
I will now start to submit a new series of patches for Winsock2-related issues. Most of it is for overlapped IO, but there are some other issues, too.
I have done a fair bit of testing with 16 and 32 bit network-oriented Windows apps, and found no regressions (well some apps wouldn't install or run with either the CVS version or my patched version of wine).
Attached is a patch that corrects martin wilck's previous patch. It just adds an if flags before deref'ing the flags variable. Not sure if this is the most correct, but it corrects the crash.
Files affected: wine/files/file.c
Patch against cvs from 04232002 with martin wilck's 4th in his last series of patch applied. Fixes a crash for aol7 and internet explorer (the only two apps I tested, probably for lots of other apps also)
On Wednesday 24 April 2002 02:20 pm, Michael Cardenas wrote:
Hello Martin.
I tested your new series of patches with aol7 and I get a crash. Attached
On Wed, 24 Apr 2002, Michael Cardenas wrote:
Attached is a patch that corrects martin wilck's previous patch. It just adds an if flags before deref'ing the flags variable. Not sure if this is the most correct, but it corrects the crash.
So flags is really an invalid pointer - can you see from which routine FILE_GetUnixHandleType is called ? That is where we should fix the bug IMO.
Martin
On Wed, 24 Apr 2002, Michael Cardenas wrote:
Attached is a patch that corrects martin wilck's previous patch. It just adds an if flags before deref'ing the flags variable. Not sure if this is the most correct, but it corrects the crash.
OK, it was a really stupid bug resulting from the fact that File_GetUnixHandle would call File_GetUnixHandleType. Strange I didn't run into it myself yet.
However I'd recommend the following patch instead of yours - please try if it also solves your problem.
Cheers and thanks for spotting this, Martin
--- files/file.c.orig Thu Apr 25 11:18:30 2002 +++ files/file.c Thu Apr 25 11:17:37 2002 @@ -361,7 +361,11 @@ */ int FILE_GetUnixHandle( HANDLE handle, DWORD access ) { - return FILE_GetUnixHandleType( handle, access, NULL, NULL ); + int ret, fd = -1; + + ret = wine_server_handle_to_fd( handle, access, &fd, NULL, NULL ); + if (ret) SetLastError( RtlNtStatusToDosError(ret) ); + return fd; }
/*************************************************************************
-
Martin Wilck -
Michael Cardenas