[Bug 970] New: - Intermittent regression tests freeze, possibly due to thread race condition.

[wine-bugs at winehq.com]

http://bugs.winehq.com/show_bug.cgi?id=970

           Summary: Intermittent regression tests freeze, possibly due to
                    thread race condition.
           Product: Wine
           Version: CVS
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: wine-kernel
        AssignedTo: wine-bugs at winehq.com
        ReportedBy: paulm at astro.gla.ac.uk


[Comments made about CVS just after Tue, 13 Aug 2002 19:44:01 +01:00 (BST) updates]

Whilst conducting the regression tests (as part of the rolling CVS regression
testing) I discovered a problem. With the version set to "win20", the process
froze at one of the wininet DLL tests. This has happened before (see [1]), but
it only occurs when emulating one of the 16-bit version of Windows (ie "win20",
"win30" or "win31") and never for other versions.

Sylvain has reported [2] problems with the wininet regression tests. The
symptoms are the same, but for me the problem is only intermittent. Once I found
an example of the problem, I haven't been able to reproduce it - even with
identical CVS trees.

When the problem occurred, I attached gdb to the process and got 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;

In this case, 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.

HTH

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

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=970>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.