https://bugs.winehq.org/show_bug.cgi?id=54055
Bug ID: 54055 Summary: winhttp:winhttp times out in Wine on fg-deb64 Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: winhttp Assignee: wine-bugs@winehq.org Reporter: fgouget@codeweavers.com Distribution: ---
Created attachment 73608 --> https://bugs.winehq.org/attachment.cgi?id=73608 winhttp: Set the default DNS resolution timeout to infinite.
winhttp:winhttp started timing out on 2022-11-24 in Wine on fg-deb64:
... winhttp.c:5215: IEProxy.ProxyBypass=(null) winhttp:winhttp:0250 done (258) in 120s 1133B
See https://test.winehq.org/data/patterns.html#winhttp:winhttp
As far as can tell the timeout started with the commit below:
commit cbfe940a1eaf5e158de3127b1265462bfbfb70af Author: Paul Gofman pgofman@codeweavers.com Date: Wed Nov 23 15:36:19 2022 -0600
winhttp: Set name resolution timeout in download_script().
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.
But then the documentation also says that the default DNS resolve timeout is 0. So maybe the attached patch would make sense?
Also I cannot reproduce the failure anymore. Maybe whatever name we're querying has been thoroughly cached by all intermediate DNS servers by now. So I should probably try that again when the DNS cache is cleared.
https://bugs.winehq.org/show_bug.cgi?id=54055
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase Assignee|wine-bugs@winehq.org |fgouget@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=54055
optimax scarre.lu@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |scarre.lu@gmail.com
--- Comment #1 from optimax scarre.lu@gmail.com --- 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.
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?
https://bugs.winehq.org/show_bug.cgi?id=54055
--- Comment #3 from optimax scarre.lu@gmail.com --- Created attachment 73713 --> https://bugs.winehq.org/attachment.cgi?id=73713 wine 7.22 log
Expected exchange with REST server, wine 7.22. In this test the REST request is refused with 403, which is the expected scenario for the purpose of reproducing the timeout issue (so that security information is not disclosed). I have anonymized urls, endpoints and passwords.
https://bugs.winehq.org/show_bug.cgi?id=54055
--- Comment #4 from optimax scarre.lu@gmail.com --- Created attachment 73714 --> https://bugs.winehq.org/attachment.cgi?id=73714 wine 8.0 rc1 log
Timeout exchange with REST server, wine 8.0 rc1. In this test the REST request times out with 408, which is not expected. I have anonymized urls, endpoints and passwords.
https://bugs.winehq.org/show_bug.cgi?id=54055
--- Comment #5 from Paul Gofman pgofman@codeweavers.com --- Tha(In reply to optimax from comment #3)
Created attachment 73713 [details] wine 7.22 log
Expected exchange with REST server, wine 7.22. In this test the REST request is refused with 403, which is the expected scenario for the purpose of reproducing the timeout issue (so that security information is not disclosed). I have anonymized urls, endpoints and passwords.
Thanks for the logs. This issue is apparently not related to the original issue concerned by this bug. I split it off into Bug 54184.
https://bugs.winehq.org/show_bug.cgi?id=54055
--- Comment #6 from Paul Gofman pgofman@codeweavers.com --- This (the original part with test timeout) should hopefully be fixed by 2b0cd25b5f5794463a59cac999583fb52fa021cc.
https://bugs.winehq.org/show_bug.cgi?id=54055
--- Comment #7 from Hans Leidekker hans@meelstraat.net --- Do you still see this François?
-
WineHQ Bugzilla