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
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@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
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@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
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
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
-
Paul Millar -
Sylvain Petreolle