Hi, it's not your recent fix cause. The app is named QQ, a very popular IM client in China. When it runs, it create two process named QQ.exe and TXPlatform.exe. The TXPlatform.exe is an out-of-process COM server, The QQ.exe is the GUI process.
When the user click the exit button of the QQ.exe, the QQ.exe and TXPlatform.exe both hang.
The backtrace of the GUI thread of QQ.exe is like this: =>0 0xf779d42e __kernel_vsyscall+0xe() in [vdso].so (0x0033e938) 1 0xf7598e1b __libc_read+0x4a() in libpthread.so.0 (0x0033e938) 2 0x7ef8ec9a wait_select_reply+0x30(cookie=0x33e968) 3 0x7ef8fac6 server_select+0x20c(select_op=0x33ea8c, size=0x8, flags=0x2, timeout=(nil)) 4 0x7ef998e7 NtWaitForMultipleObjects+0xbc(count=0x1, handles=0x33ebe0, wait_any=1, alertable=0, timeout=(nil)) 5 0x7ecbcd31 WaitForMultipleObjectsEx+0x191 in kernel32 (0x0033ecf8) 6 0x7e13c224 CoWaitForMultipleHandles+0x4e2 in ole32 (0x0033edf8) 7 0x7e1775b8 ClientRpcChannelBuffer_SendReceive+0x598 in ole32 (0x0033eef8)
...
And the backtrace of another thread of QQ.exe is like this: Backtracing for thread 0080 in process 003c (C:\Program Files\Tencent\QQ\Bin\QQ.exe): Backtrace: =>0 0xf779d42e __kernel_vsyscall+0xe() in [vdso].so (0x020ce2a8) 1 0xf7598e1b __libc_read+0x4a() in libpthread.so.0 (0x020ce2a8) 2 0x7ef8ec9a wait_select_reply+0x30(cookie=0x20ce2d8) 3 0x7ef8fac6 server_select+0x20c(select_op=0x20ce3fc, size=0x8, flags=0x2, timeout=(nil)) 4 0x7ef998e7 NtWaitForMultipleObjects+0xbc(count=0x1, handles=0x20ce550, wait_any=1, alertable=0, timeout=(nil)) 5 0x7ecbcd31 WaitForMultipleObjectsEx+0x191 6 0x7ecbcae7 WaitForSingleObject+0x45 7 0x7e179258 dispatch_rpc+0x350(msg=0x3f24668) in ole32 (0x020ce788) 8 0x7e0c10fa process_request_packet+0x3b8(conn=0x158370, hdr=0x55a12e8, msg=0x3f24668) in rpcrt4 (0x020ce8c8) 9 0x7e0c15c6 RPCRT4_process_packet+0x114(conn=0x158370, hdr=0x55a12e8, msg=0x3f24668, auth_data=0x0(nil), auth_length=0) in rpcrt4 (0x020ce928) 10 0x7e0c1759 RPCRT4_worker_thread+0x4e( in rpcrt4 (0x020ce978)
...
The dispatch_rpc thread has post a 0x400 RPC message to the GUI thread and is waiting for GUI thread to process the RPC request. But the GUI thread has received WM_QUIT message, the message_loop variable set to FALSE and it only wait for event signal, so the 0x400 RPC message can't be handled.
The TXPlatform.exe hang because it is waiting for dispatch_rpc thread send RPC result to a named pipe.
Because the hang is too complex , I don't know how to add a test for it.
------------------ Original ------------------ From: "Sebastian Lackner"sebastian@fds-team.de; Date: Wed, Dec 3, 2014 06:42 PM To: "liuchanghui"liuchanghui@linuxdeepin.com; Cc: "wine-devel"wine-devel@winehq.org; Subject: Re: ole32: fixed CoWaitForMultipleHandles cause app hang
On 03.12.2014 08:15, Changhui Liu wrote:
Do I understand you correctly that this is caused by my recent fix of CoWaitForMultipleHandles? Which app is it? Your change might be correct, but to ensure that this is the case please add a test for it: http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ole32/tests/compobj.c#... Moreover you should completely remove old code then, not just comment it out.
Regards, Sebastian