[Bug 54055] New: winhttp:winhttp times out in Wine on fg-deb64
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(a)winehq.org Reporter: fgouget(a)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(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54055 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase Assignee|wine-bugs(a)winehq.org |fgouget(a)codeweavers.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54055 optimax <scarre.lu(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |scarre.lu(a)gmail.com --- Comment #1 from optimax <scarre.lu(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54055 Paul Gofman <pgofman(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pgofman(a)codeweavers.com --- Comment #2 from Paul Gofman <pgofman(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54055 --- Comment #3 from optimax <scarre.lu(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54055 --- Comment #4 from optimax <scarre.lu(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54055 --- Comment #5 from Paul Gofman <pgofman(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54055 --- Comment #6 from Paul Gofman <pgofman(a)codeweavers.com> --- This (the original part with test timeout) should hopefully be fixed by 2b0cd25b5f5794463a59cac999583fb52fa021cc. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54055 --- Comment #7 from Hans Leidekker <hans(a)meelstraat.net> --- Do you still see this François? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla