https://bugs.winehq.org/show_bug.cgi?id=54055
Paul Gofman pgofman@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pgofman@codeweavers.com
--- Comment #2 from Paul Gofman pgofman@codeweavers.com --- Created attachment 73712 --> https://bugs.winehq.org/attachment.cgi?id=73712 Test
I'm not totally sure because the failure is not actually 100% reproducible and gave > > some bad results a couple of times. But having it point at this commit makes sense.
- WinHttpSetTimeouts( ses, 5000, 60000, 30000, 30000 );
The timeouts disappeared when I changed the resolve timeout from 5000 ms to 0 (no timeout). So... I have a slow DNS setup? That may actually be true since it's somewhat complicated.
My patch only reduced the timeout and doesn't change anything WRT timeouts on any other requests besides downloading proxy config script which is done by winhttp internally.
I have one guess though. The test passes NULL lpszAutoConfigUrl and it is not checked. Previously without any timeout it went to GetAddrInfoW() directly and was probably just getting an error. With the timeout set with the patch it goes through an async thread and might be crashing on wcsdup() on this name.
Could you please try with the attached patch (it is to winhttp, not test) if possible if it fixes the issue?
We might have this same problem with our application developed in Delphi running Wine on Ubuntu / KUbuntu 20.04, and it seems to be a regression from 7.22. The application issues https REST request to a server in the cloud.
With Wine 7.22 there is no issue, the application can run for days or weeks with regular REST requests always succeeding.
After upgrading to Wine 8.0-rc1, all requests fail with 408 timeout.
Reverting to Wine 7.22 fixes the problem.
The patch in question is present in 7.22 though? Could you please attach WINEDEBUG=+pid,+loaddll,+winhttp,+seh,+unwind log from the failing run on 8.0-rc1? And ideally from the successful run on 7.22 as well?