Hi,
According to WRT [1], one of todays patches caused a regression error, picked up by one of the wininet DLL tests. Only, none of the patches seem to have touched wininet.
The problem is with the tests at dlls/wininet/tests/http.c lines 117 and 157. The test freezes for up to 4 minutes, then returns the failures.
As an act in desperation, I've tried reversing some of the patches (1-4, 6, and 7 from the WRT list) without success.
I'm also a little suspicious that this might be something to do with Glasgow (or me :) I've been able to reproduce the problem on two other (local) machines, but I've not tried on any remote machines. I've also tried using earlier cvs versions (from a few days ago), but that build fails the wininet tests too. It would be good if someone could confirm the problem.
Sorry if this turns out to be a red herring ...
Paul.
PS It's quite late here, so I might not be able to reply until tomorrow.
[1] http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php
---- Paul Millar
http://www.winehq.com/hypermail/wine-devel/2002/07/0386.html
--- Paul Millar paulm@astro.gla.ac.uk a écrit : > Hi,
According to WRT [1], one of todays patches caused a regression error, picked up by one of the wininet DLL tests. Only, none of the patches seem to have touched wininet.
The problem is with the tests at dlls/wininet/tests/http.c lines 117 and 157. The test freezes for up to 4 minutes, then returns the failures.
As an act in desperation, I've tried reversing some of the patches (1-4, 6, and 7 from the WRT list) without success.
I'm also a little suspicious that this might be something to do with Glasgow (or me :) I've been able to reproduce the problem on two other (local) machines, but I've not tried on any remote machines. I've also tried using earlier cvs versions (from a few days ago), but that build fails the wininet tests too. It would be good if someone could confirm the problem.
Sorry if this turns out to be a red herring ...
Paul.
PS It's quite late here, so I might not be able to reply until tomorrow.
[1] http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php
Paul Millar
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
On Thu, 1 Aug 2002, [iso-8859-1] Sylvain Petreolle wrote:
http://www.winehq.com/hypermail/wine-devel/2002/07/0386.html
Hi Sylvain,
Sorry, I meant to reply to that email earlier. I've notice the same or similar thing with WRT. If you look at around Friday July 19 (see Win3.0 tests column in [1]), you'll see four tests weren't conducted. Next build cycle they were.
The same thing happened earlier, although less clearly, around 5th July (see [2]). On Friday, new regression tests were added, two of which failed straight away (the C:, D: problem). Because the tests are only known by their file-name and line-number, the new tests cause the "-27 tests +42 tests" on each build. Except, for Win2.0 tests 31 tests were not conducted, ie 4 extra test. The following Monday, these tests were conducted, but 4 tests were not conducted for the Win3.1 platform, only for those tests to be conducted on Tuesday (+59 tests for Win3.1 instead of +55).
What happened was this: the patches tend to be applied during the night (local time) and unless I happen to be working late, I discover the effects of the patches in the morning. For those particular builds I discovered that the regression tests had frozen, just as you describe. I had to kill wine so the cycle could complete. With a bit of detective work, I traced the problem down to wininet. It seemed that the exact order in which the tests are run is random (multiple threads? -- I haven't had a chance to check the code yet).
As the problem didn't immediately resurface after Monday 8th July, I assumed that it was a low-probability thread contention/deadlock issue. I tried conducting just the regression tests for wininet, without being able to reproducing the problem, but I didn't think to try the whole tests (just assumed that the tests were independent).
It looks like something has changed, so the occasional-hard-lock problem has been replaced by the system freezing for many minutes before reporting a regression test failure.
So, Sylvain, when you run the tests now, does it eventually time-out returning a error, or does it freeze forever?
Cheers,
Paul
[1] http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php?max=5&start=102 [2] http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php?max=5&start=94
---- Paul Millar
--- Paul Millar paulm@astro.gla.ac.uk a �crit�: > Hi,
According to WRT [1], one of todays patches caused a regression error, picked up by one of the wininet DLL tests. Only, none of the patches seem to have touched wininet.
The problem is with the tests at dlls/wininet/tests/http.c lines 117 and 157. The test freezes for up to 4 minutes, then returns the failures.
As an act in desperation, I've tried reversing some of the patches (1-4, 6, and 7 from the WRT list) without success.
I'm also a little suspicious that this might be something to do with Glasgow (or me :) I've been able to reproduce the problem on two other (local) machines, but I've not tried on any remote machines. I've also tried using earlier cvs versions (from a few days ago), but that build fails the wininet tests too. It would be good if someone could confirm the problem.
Sorry if this turns out to be a red herring ...
Paul.
PS It's quite late here, so I might not be able to reply until tomorrow.
Paul Millar paulm@astro.gla.ac.uk writes:
As the problem didn't immediately resurface after Monday 8th July, I assumed that it was a low-probability thread contention/deadlock issue. I tried conducting just the regression tests for wininet, without being able to reproducing the problem, but I didn't think to try the whole tests (just assumed that the tests were independent).
Note that the wininet tests try to connect to www.winehq.com, so the failure could be caused by a network connectivity problem (of course it may also be a bug in our code).
On 1 Aug 2002, Alexandre Julliard wrote:
Note that the wininet tests try to connect to www.winehq.com, so the failure could be caused by a network connectivity problem (of course it may also be a bug in our code).
Actually, the networking turned out to be the problem after all. Web proxies here at Glasgow Uni are a little complex (and IMO sub-optimal). The problem was with a machine Comp.Serv. forgot to reboot after a UPS died (killed by lightning). This lead to the situation where I could see www.winehq.com, but quisquiliae couldn't.
The weird thing is that the calls to InternetConnectA() and HttpOpenRequestA() in dlls/wininet/tests/http.c succeeded despite the connection failing. Is this correct? The MSDN entries ([1] and [2]) suggest that they should fail if the connection cannot be made, but the code says otherwise ...
Cheers,
Paul.
[1] http://msdn.microsoft.com/workshop/networking/wininet/reference/functions/in... [2] http://msdn.microsoft.com/workshop/networking/wininet/reference/functions/ht...
---- Paul Millar
So, Sylvain, when you run the tests now, does it eventually time-out returning a error, or does it freeze forever?
Paul, Will try it this evening (I'm currently at work ;))
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Does this mean our tests aren't thread safe ?(hope i'm saying what I want :/) I wouldn't leave a real hole of black magic (M$) to have an open-source hole of black magic ;) :)).
As the problem didn't immediately resurface after Monday 8th July, I assumed that it was a low-probability thread contention/deadlock issue. I tried conducting just the regression tests for wininet, without being able to reproducing the problem, but I didn't think to try the whole tests (just assumed that the tests were independent).
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
So, Sylvain, when you run the tests now, does it eventually time-out returning a error, or does it freeze forever?
it freezes forever now. (just updated/recompiled CVS 10 min ago) also running it under gdb gives this result:
(gdb) run test Starting program: /usr/bin/make test (no debugging symbols found)...(no debugging symbols found)... ../../programs/winetest/runtest -q -P wine -M wininet.dll -T ../.. -p tests/wininet_test.exe.so tests/http.c && touch tests/http.ok tests/http.c:176: Test failed: InternetCloseHandle failed make: *** [tests/http.ok] Erreur 1 (no debugging symbols found)... Program exited with code 02. (gdb)
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
make test sudenly pass a minute ago, without reason. rerunning make testclean ; make test freezes. then i ctrl-c, rerun make test and the test randomly freezes/ fails on line 176.
--- Sylvain Petreolle spetreolle@yahoo.fr a écrit : >
So, Sylvain, when you run the tests now, does it eventually
time-out
returning a error, or does it freeze forever?
it freezes forever now. (just updated/recompiled CVS 10 min ago) also running it under gdb gives this result:
(gdb) run test Starting program: /usr/bin/make test (no debugging symbols found)...(no debugging symbols found)... ../../programs/winetest/runtest -q -P wine -M wininet.dll -T ../.. -p tests/wininet_test.exe.so tests/http.c && touch tests/http.ok tests/http.c:176: Test failed: InternetCloseHandle failed make: *** [tests/http.ok] Erreur 1 (no debugging symbols found)... Program exited with code 02. (gdb)
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
-
Alexandre Julliard -
Paul Millar -
Sylvain Petreolle