Problem with regression tests getting stuck

[Paul Millar]

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

[Sylvain Petreolle]

Paul,
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%.

(even if gcc 3.2 is a bit slower to compile wine;))

For Codeweavers webmaster:

Tried to update bug #852 but have a bugzilla error:
SELECT profiles.realname, profiles.login_name, longdescs.bug_when,     
  longdescs.thetext FROM longdescs, profiles WHERE profiles.userid =
longdescs.who       AND longdescs.bug_id = 852 ORDER BY
longdescs.bug_when: Can't find record in 'longdescs' at globals.pl line
231.

(30/08 08 PM EST)



 --- Paul Millar <paulm(a)astro.gla.ac.uk> 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

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

[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 <paulm(a)astro.gla.ac.uk> 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

[Sylvain Petreolle]

I tested wine with 3 different compilers at this time:
- orignial RedHat's gcc 2.96 (The_Bad_Thing);
- gcc3 patched to hell Redhat gcc 3.1 (better but not good)
- gcc 3.2 from gcc.gnu.org tarball "The source, Luke." ;)

2.96 doesn't pass the tests,
3.1 too,
3.2 from source passes. 

(and I did a _bunch_ of tests.)
> 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.
> if you want to say "fucked up", I'm ok (ask to mplayer.hq.hu guys ;))
> if you want to say it's clean, I don't agree in any point.
> > (even if gcc 3.2 is a bit slower to compile wine;))
>
> How much of a performance hit do you suffer here?
> described by gcc team (and others), gcc 3.2 is about 5% slower than 3.0
> (don't know why)

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

[Paul Millar]

On Wed, 4 Sep 2002, [iso-8859-1] Sylvain Petreolle wrote:
> I tested wine with 3 different compilers at this time:
> - orignial RedHat's gcc 2.96 (The_Bad_Thing);
> - gcc3 patched to hell Redhat gcc 3.1 (better but not good)
> - gcc 3.2 from gcc.gnu.org tarball "The source, Luke." ;)
>
> 2.96 doesn't pass the tests,
> 3.1 too,
> 3.2 from source passes. 
> (and I did a _bunch_ of tests.)

Ok, I'll go for pristine 3.2 gcc when I get a moment.
> > 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.
> > if you want to say "fucked up", I'm ok (ask to mplayer.hq.hu guys ;))
> > if you want to say it's clean, I don't agree in any point.

The first: a complete fuck-up. Specifically, when they released RH7.0 w/
gcc "v2.96" the Alpha version was truly awful.  Many rather critical
(networking) RPM packages just didn't work. But, simply recompiling using
a proper version of gcc seemed to solved the problem ...
> > > (even if gcc 3.2 is a bit slower to compile wine;))
> >
> > How much of a performance hit do you suffer here?
> > described by gcc team (and others), gcc 3.2 is about 5% slower than 3.0
> > (don't know why)

Ok, that's not too bad.

Cheers,

Paul.

----
Paul Millar