Hello,
I'm testing a windows app I'd very much like to run under Wine (using v0.9.22), being in touch with the author. This is a small web server app based on a Microsoft MFC sample app. It happily works under Windows, but that'd be the wrong thing for running it 24/7. ;-)
It's not yet working under Wine, fails to serve larger files, but we've pretty much narrowed down the problem by adding logs to the app and using ethereal.
For example, the app tries to write 25017 bytes to the socket, but the socket only allows 11680 bytes at a time, and the TCP stack fragments this in 8 packets of 1460 bytes, presumably because it only has 8 buffers reserved. So far so good.
We see them being sent on the Ethernet and the ACK's are coming in, but after these 8 packets there should be a signal to trigger the OnSend function of the app so it can send the next part of data, but this never happens... The reselection of the socket did not return an error. Given the reselection is ok, and at the Ethernet level messages are consistently sent and ACK's received, the conclusion is that there might be a bug in Wine. So here we are stuck.
Given that Wine successfully runs real big application such as MS Internet Explorer, I can't imagine it to have such a fundamental problem. Is there something I overlooked, like a configuration issue?
If it really gets interesting, I can ask the developer for a more detailed report, including the Ethereal log snippet, in case somebody wants to actually look into it. First I'd like to find out if this is the right place, or if I should "bury" it into bugzilla.
Thank you for your time and help, Jörg
Am Sonntag 08 Oktober 2006 23:28 schrieb [IDC]Dragon:
For example, the app tries to write 25017 bytes to the socket, but the socket only allows 11680 bytes at a time, and the TCP stack fragments this in 8 packets of 1460 bytes, presumably because it only has 8 buffers reserved. So far so good.
Not sure if I understand what the app is doing, but afaik no socket implementation guarantees that any amount of data can be sent out at once. If send() succeeds it returns the amount of data sent, and if you request it to send 25017 bytes it can send anything from 1 byte to 25017 byte.
How much it actually sends depends on the network settings(try playing around with ifconfig), the network activity on the socket, etc. After all, not even windows guarantees that a specific amount of data is sent at once(although the mfc might do that, not sure).
Does the application / mfc expect any notification when all the data is sent? not sure.
On Sun, Oct 08, 2006 at 11:28:10PM +0200, [IDC]Dragon wrote:
We see them being sent on the Ethernet and the ACK's are coming in, but after these 8 packets there should be a signal to trigger the OnSend function of the app so it can send the next part of data, but this never happens... The reselection of the socket did not return an error.
There are various bugs reports that sound similar: Bug 3777 - Calling closesocket() will not eject any accept()s waiting in blocking mode... http://bugs.winehq.org/show_bug.cgi?id=3777 Bug 4619 - Warcraft III infinite timeout when trying to connect a badly hosted game on battle.net http://bugs.winehq.org/show_bug.cgi?id=4619
I also experienced a similar bug while trying to login with Conquer Online ( http://appdb.winehq.org/appview.php?iVersionId=4055 ).
I'm not sure to what extend those are the exact same problem though.
Jan
Jan Zerebecki wrote:
On Sun, Oct 08, 2006 at 11:28:10PM +0200, [IDC]Dragon wrote:
We see them being sent on the Ethernet and the ACK's are coming in, but after these 8 packets there should be a signal to trigger the OnSend function of the app so it can send the next part of data, but this never happens... The reselection of the socket did not return an error.
There are various bugs reports that sound similar: Bug 3777 - Calling closesocket() will not eject any accept()s waiting in blocking mode... http://bugs.winehq.org/show_bug.cgi?id=3777 Bug 4619 - Warcraft III infinite timeout when trying to connect a badly hosted game on battle.net http://bugs.winehq.org/show_bug.cgi?id=4619
I also experienced a similar bug while trying to login with Conquer Online ( http://appdb.winehq.org/appview.php?iVersionId=4055 ).
I'm not sure to what extend those are the exact same problem though.
Jan
the two first bugs are unrelated, as the problem is more around sending sets of data while connected, rather than asynchronous operations on close/connect... sockets to me, I wouldn't be surprised if overlapped I/O on sockets are to blame a +ntdll trace would be helpful A+
to me, I wouldn't be surprised if overlapped I/O on sockets are to blame a +ntdll trace would be helpful
How do I enable that? (likely a noob question)
From your comments I take it's no setup problem on my side, could be a real bug.
Meanwhile I got some more info from the developer, relaying your responses, sorry for the odd communication. ;-)
I used that to create a fully featured bugzilla entry: http://bugs.winehq.org/show_bug.cgi?id=6415
Thanks Jörg
a +ntdll trace would be helpful
How do I enable that? (likely a noob question)
WINEDEBUG=+ntdll wine foo.exe
OK, got it. I have attached a log to the bugzilla entry.
In addition, I also now attached an executable, complete with sample data, so anybody may quickly reproduce it. This is not our WRC app, but the plain vanilla Microsoft sample, which needs no install. It also shows the problem, and even more drastic (failing to serve a small file, too).
Thanks to everyone! Jörg
[IDC]Dragon wrote:
a +ntdll trace would be helpful
How do I enable that? (likely a noob question)
WINEDEBUG=+ntdll wine foo.exe
OK, got it. I have attached a log to the bugzilla entry.
In addition, I also now attached an executable, complete with sample data, so anybody may quickly reproduce it. This is not our WRC app, but the plain vanilla Microsoft sample, which needs no install. It also shows the problem, and even more drastic (failing to serve a small file, too).
Thanks to everyone! Jörg
does the attached patch solve your issues ? A+
diff --git a/server/sock.c b/server/sock.c index ce63932..c1a7a8d 100644 --- a/server/sock.c +++ b/server/sock.c @@ -814,6 +814,7 @@ DECL_HANDLER(set_socket_event) FILE_WRITE_ATTRIBUTES, &sock_ops))) return; old_event = sock->event; sock->mask = req->mask; + sock->hmask &= ~req->mask; /* re-enable held events */ sock->event = NULL; sock->window = req->window; sock->message = req->msg;
I'd like to humbly bump my bug report: http://bugs.winehq.org/show_bug.cgi?id=6415
Now somebody else seems to suffer a perhaps related problem, and we offer a donation for fixing it. This certainly doesn't really pay for anybodys time, but perhaps it's a sign. Bear in mind that I also spent many hours in pinpointing the problem, and did my best in providing a small to-the-point executable example, source code, and logs. (You'd like my web server demo content ;-) It's as much on a silver tablet with red velvet as I can present it. Would be a shame to have it rot in bugzilla.
Thanks for attention Jörg
On Saturday 30 December 2006 09:20, [IDC]Dragon wrote:
I'd like to humbly bump my bug report: http://bugs.winehq.org/show_bug.cgi?id=6415
I've had a look at it and couldn't recreate the problem. What setup do you have? (I'm not running the web server on port 80, because that's where my apache is sitting, and I don't feel like running wine as root. I'd be surprised if that changes anything, though.)
Looking at my +winsock trace, it seems to be looping over the WSASendTo just fine.
Cheers, Kai
-
[IDC]Dragon -
Eric Pouech -
Jan Zerebecki -
Kai Blin -
Stefan Dösinger