http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #82 from Daniel Santos daniel.santos@pobox.com 2008-07-21 17:40:58 --- AJ has accepted my patch, commit here: http://source.winehq.org/git/wine.git/?a=commit;h=b54b282a4f89da3809ae0e166a... Does this mean the bug can be closed as fixed or does that have to wait for the new release?
(In reply to comment #77)
just out of intrest, if I get this right then the following is what is going wrong with lotro:
lotro -> WSASendTo (sending an udp package) lotro -> WSASetLastError (checking to see if it went right, eventhough WSASendTo returned that all went right, waste of time/resources)
Situation some of us then seem to get is:
lotro -> WSASendTo fails from some reason and sets LastError. lotro -> WSASetLastError shows error lotro -> WSASendTo resends and success lotro -> WSASetLastError returns the previous error lotro -> WSASendTo resends and success lotro -> WSASetLastError returns the previous error
etc. etc. filling up our bandwidth until some unknown other function sets LastError to 0 and lotro see that and stops the udp burst ?
Replace WSASetLastError() with WSAGetLastError() because this is what the lotro executable actually calls and this is correct.
What I cant place in the above is how this can be so area specific, meaning I have no issue at position X in the game and take 2 steps east and there it goes, take 2 steps west and its fine again.
Pin-pointing stuff like this when you don't have the code can be pretty challenging. None the less, I'm pretty certain it's related to being in proximity to some world object or npc that requires a special function (in the code) to manage it, and this is where said function has the problem. Alternately, it may just be the order of calls being made given various world objects and/or special npcs (for instance, only happens when a mailbox is within 200m). Stuff like this can be tricky. Either way, it's exceedingly common to call WSARecvFrom and have it fail with WSAWOULDBLOCK (I think 1005 decimal, something like that), so the "wsa last error" is freqently non-zero.
But if you are depending upon the result of WSAGetLastError() when the docs for WSASendTo() don't tell you its set, you're asking for trouble.
Oh well, as Dan said, nice catch, hope it gets approved, till then using the custom dll in lotro directory.
Have you tested your proposed fix Daniel ? same resuls or better even as your custom dll ?
Oh and Dan, should this not be in all ws2_32 functions ?
Thanks! :) And it finally did get approved! I actually had problems with my own testing, when I ran dlls/ws2_32/tests/ws2_32_tests.exe.so sock on my linux box, I got a lot of failures (not from my patch though). I finally got to a windows xp laptop and got wine compiled for tests, but the tests still failed with one error (with and without my patch). I presume somebody else has tested and satisfied AJ, because I never got a zero failures build on windows :(
Also, performance using the WSASetLastError compared to my previous hack is much better, packet count and bandwidth is WAY less, because there were still non-identical packets that were spamming, just not as bad as the duplicates. What I notice most is when players are using /music, the notes appear to be arriving on time, whereas before, the notes were out of time.