Re: Problem with regression tests getting stuck

[Paul Millar]

Hi Sylvian,

On Fri, 30 Aug 2002, [iso-8859-1] Sylvain Petreolle wrote:
> I recently tried to compile gcc 3.2 from sources on my RedHat 7.3.
> It seems that it is a gcc 2.96 bug as tests now pass 100%.

Actually, one of the annoying things about this is I've never managed to
reproduce the bug in a "controlled" environment. Even repeatedly running
the regression tests in a loop on the same machine and just waiting for it
to freeze: nada! It only seems to happen during a WRT-update. There are
some differences, but only in terms of pipes and filters: nothing that
should affect the outcome.

I could switch to gcc-3.1 and see if that fixes it but, as Mr Holmes would
have it, absence of evidence is not evidence of absence :)

Besides, too often I've seen some completely wacky behaviour of seemingly
innocuous code (which I was convinced was because of compiler-error) only
for some subtle code-related bug to turn out to be the culprit.

That said, gcc-2.96 was/is a completely fscked up "release" of gcc.
> (even if gcc 3.2 is a bit slower to compile wine;))

How much of a performance hit do you suffer here?
> --- Paul Millar  a �crit�:
> > Hi everyone,
> > I've had the regression tests freeze on me again (see [1] for
> > previous
> > report). Sylvain has reported problems with the wininet regression
> > tests
> > (described in [2]). The symptoms are the same, but for me the problem
> > is
> > only intermittent. This time I caught the problem with gdb and
> > obtained
> > the following info:
> >
> > [...]
> > Loaded symbols for /lib/libresolv.so.2
> > 0x402e7744 in __libc_close () at __libc_close:-1
> > -1      __libc_close: No such file or directory.
> >         in __libc_close
> > (gdb) bt
> > #0  0x402e7744 in __libc_close () at __libc_close:-1
> > #1  0x400ec9a4 in __DTOR_END__ ()
> >    from /home/paulm/WINE-cvs/wine/dlls/libntdll.dll.so
> > #2  0x400b3df5 in WaitForMultipleObjectsEx (count=0, handles=0x0, 
> > wait_all=0, 
> >     timeout=100, alertable=0) at ../../scheduler/synchro.c:257
> > #3  0x400b3b88 in Sleep (timeout=100) at
> > ../../scheduler/synchro.c:178
> > #4  0x40358747 in winapi_test (flags=268435456) at tests/http.c:121
> > #5  0x40358b36 in func_http () at tests/http.c:184
> > #6  0x40358f9d in run_test (name=0xbffffc63 "http.c") at wtmain.c:244
> > #7  0x40357037 in __wine_exe_main () at wininet_test.exe.spec.c:133
> > #8  0x400aff84 in start_process () at ../../scheduler/process.c:528
> > #9  0x400b3f3f in call_on_thread_stack (func=0x400afd2c)
> >     at ../../scheduler/sysdeps.c:108
> >
> > So, to summarise (with some extra bits of information):
> >
> > The problem occurs when wininet/tests/http.c is testing asynchronous
> > HttpSendRequest(), so flags > 0. The problem is triggered at line 121
> > of 
> > http.c, i.e.:
> > 120    while ((flags)&&(!goon))
> > 121        Sleep(100);
> >
> > Sleep(), in turn, just calls WaitForMultipleObjectsEx(). From 
> > scheduler/synchro.c:
> > 176	VOID WINAPI Sleep( DWORD timeout )
> > 177	{
> > 178	    WaitForMultipleObjectsEx( 0, NULL, FALSE, timeout, FALSE );
> > 179	}
> >
> > WaitForMultipleObjectsEx() has problems when it gets to 257:
> > 256	        SERVER_END_REQ;
> > 257	        if (ret == STATUS_PENDING) ret = wait_reply( &cookie );
> > 258	        if (ret != STATUS_USER_APC) break;
> >
> > ret is 1079729528, btw.
> >
> > AFAIK, __DTOR_END__ (see near bottom of stack) is the destructor for
> > a
> > function call in ntdll. I'm probably missing something obvious, but I
> > don't see the connection between scheduler/synchro.c:257 and ntdll.
> > The
> > closest is wait_reply() (in scheduler/client.c) calls wait_reply_data
> > (in
> > same file), which calls NtCurrentTeb(), which is commented as an
> > NTDLL
> > function. But there doesn't seem to be an implementation of
> > NtCurrentTeb
> > in ntdll.
> >
> > Any ideas?
> >
> > Cheers,
> >
> > Paul.
> >
> > [1] http://www.winehq.com/hypermail/wine-devel/2002/08/0006.html
> > [2] http://www.winehq.com/hypermail/wine-devel/2002/07/0386.html
> >
> > PS, I'll create a bugzilla in a bit.

----
Paul Millar