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.