[Bug 28470] New: qmgr tests deadlock with WINEDEBUG=warn+heap on slower machines

http://bugs.winehq.org/show_bug.cgi?id=28470

Summary: qmgr tests deadlock with WINEDEBUG=warn+heap on slower
                    machines
           Product: Wine
           Version: 1.3.28
          Platform: x86
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: qmgr
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]

On my e8400, when run with WINEDEBUG=warn+heap, the qmgr conformance
tests seem to lock up very frequently.  Here's a backtrace
gotten with btall:

Backtracing for thread 0034 in process 0008
(Z:\home\dank\wine-git\dlls\qmgr\tests\qmgr_test.exe):
Backtrace:
=>0 GLIBC_2+0x830() in ld-linux.so.2 (0x0043e738)
  1 ReadFile+0x265(hFile=0x4c, buffer=0x43e86c, bytesToRead=0x10,
bytesRead=0x43e80c, overlapped=(nil)) [dlls/kernel32/file.c:439]
  2 rpcrt4_conn_np_read+0x3c(Connection=0x12c080, buffer=0x43e86c, count=0x10)
[dlls/rpcrt4/rpc_transport.c:420]
  3 RPCRT4_receive_fragment+0xb4(Connection=0x12c080, Header=0x43e96c,
Payload=0x43e908) [dlls/rpcrt4/rpc_binding.h:177]
  4 RPCRT4_ReceiveWithAuth+0x7c(Connection=0x12c080, Header=0x43e96c,
pMsg=0x33fb54, auth_data_out=(nil), auth_length_out=0x0(nil))
[dlls/rpcrt4/rpc_message.c:1396]
  5 I_RpcReceive+0x7b(pMsg=0x33fb54) [dlls/rpcrt4/rpc_message.c:1553]
  6 I_RpcSendReceive+0x7f(pMsg=0x33fb54) [dlls/rpcrt4/rpc_message.c:1911]
  7 rpc_sendreceive_thread+0x23(param=0x12d134) [dlls/ole32/rpc.c:794]
  8 worker_thread_proc+0xe1(param=0x0(nil)) [dlls/ntdll/threadpool.c:114]
  9 call_thread_func+0xb() in ntdll (0x0043ea78)
  10 call_thread_entry_point+0x6d(entry=0x7bc7ec30, arg=0x0(nil))
[dlls/ntdll/signal_i386.c:2499]
  11 start_thread+0xf7(info=0x7ffd4fb8) [dlls/ntdll/thread.c:405]

Backtracing for thread 0009 in process 0008
(Z:\home\dank\wine-git\dlls\qmgr\tests\qmgr_test.exe):
Backtrace:
=>0 GLIBC_2+0x830() in ld-linux.so.2 (0x0033f228)
  1 NTDLL_wait_for_multiple_objects+0x232(count=0x2, handles=0x33f4a8,
flags=0x4, timeout=(nil), signal_object=<?>) [dlls/ntdll/sync.c:1124]
  2 NtWaitForMultipleObjects+0x5a(count=0x2, handles=0x33f4a8, wait_all=0,
alertable=0, timeout=(nil)) [dlls/ntdll/sync.c:1162]
  3 WaitForMultipleObjectsEx+0xee(count=0x2, handles=0x33f67c, wait_all=0,
timeout=0xffffffff, alertable=0) [dlls/kernel32/sync.c:188]
  4 nulldrv_MsgWaitForMultipleObjectsEx+0x31(count=0x2, handles=0x33f67c,
timeout=0xffffffff, mask=0x4ff, flags=0) [dlls/user32/driver.c:359]
  5 wait_message+0x47(count=0x2, handles=0x33f67c, timeout=0xffffffff,
mask=0x4ff, flags=0) [dlls/user32/winproc.c:1126]
  6 MsgWaitForMultipleObjectsEx+0x109(count=0x1, pHandles=0x12d154,
timeout=0xffffffff, mask=0x4ff, flags=0) [dlls/user32/message.c:3944]
  7 CoWaitForMultipleHandles+0xd6(dwFlags=0, dwTimeout=0xffffffff,
cHandles=0x1, pHandles=0x12d154, lpdwindex=0x33f91c)
[dlls/ole32/compobj.c:3712]
  8 ClientRpcChannelBuffer_SendReceive+0x5fb(iface=0x12c220, olemsg=0x33fb54,
pstatus=0x33f96c) [dlls/ole32/rpc.c:903]
  9 NdrProxySendReceive+0x71(This=0x12d02c, pStubMsg=0x33fa74)
[dlls/rpcrt4/cproxy.c:487]
  10 IRemUnknown_RemRelease_Proxy+0x1c6(This=0x12d02c, cInterfaceRefs=0x1,
InterfaceRefs=0x33fbd4) [dlls/ole32/dcom_p.c:639]
  11 ifproxy_release_public_refs+0xe3(This=0x12c190) [dlls/ole32/marshal.c:673]
  12 ifproxy_destroy+0x24(This=0x12c190) [dlls/ole32/marshal.c:708]
  13 ClientIdentity_Release+0xc8(iface=0x12b940) [dlls/ole32/marshal.c:1109]
  14 IUnknown_Release_Proxy+0x65(iface=0x12c1f4) [dlls/rpcrt4/cproxy.c:418]
  15 func_enum_files+0x179() [dlls/qmgr/tests/enum_files.c:98]
  16 run_test+0x143(name="enum_files.c")
[dlls/qmgr/tests/../../../include/wine/test.h:556]
  17 main+0x161(argc=0x33f248, argv=0x682a6a9f)
[dlls/qmgr/tests/../../../include/wine/test.h:624]
> From the second stack, it looks like it was just trying to tear down

the test.  Race condition and/or reference count problem, perhaps?