[PATCH 0/1] MR1591: combase: Use SendMessageW() in ClientRpcChannelBuffer_SendReceive() for STAs.

[Zhiyi Zhang (＠zhiyi)]

An application has a thread 1 sending WM_DESTROY to windows in thread 2. When handling the message
in thread 2, RevokeDragDrop() is called to release a COM object in thread 1. Then deadlock happens
when using PostMessageW() because the DM_EXECUTERPC message will not be handled as thread 1 is still
waiting for thread 2 to finish handling WM_DESTROY.

[PATCH 1/1] combase: Use SendMessageW() in ClientRpcChannelBuffer_SendReceive() for STAs.

[Zhiyi Zhang]

From: Zhiyi Zhang

An application has a thread 1 sending WM_DESTROY to windows in thread 2. When handling the message
in thread 2, RevokeDragDrop() is called to release a COM object in thread 1. Then deadlock happens
when using PostMessageW() because the DM_EXECUTERPC message will not be handled as thread 1 is still
waiting for thread 2 to finish handling WM_DESTROY.
---
 dlls/combase/rpc.c | 11 +----------
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/dlls/combase/rpc.c b/dlls/combase/rpc.c
index c51b59de4bf..1862c8bddca 100644
--- a/dlls/combase/rpc.c
+++ b/dlls/combase/rpc.c
@@ -1416,16 +1416,7 @@ static HRESULT WINAPI ClientRpcChannelBuffer_SendReceive(LPRPCCHANNELBUFFER ifac

msg->ProcNum &= ~RPC_FLAGS_VALID_BIT;

-        if (!PostMessageW(message_state->target_hwnd, DM_EXECUTERPC, 0,
-                          (LPARAM)&message_state->params))
-        {
-            ERR("PostMessage failed with error %lu\n", GetLastError());
-
-            /* Note: message_state->params.iface doesn't have a reference and
-             * so doesn't need to be released */
-
-            hr = HRESULT_FROM_WIN32(GetLastError());
-        }
+        SendMessageW(message_state->target_hwnd, DM_EXECUTERPC, 0, (LPARAM)&message_state->params);
     }
     else
     {

[PATCH 1/1] combase: Use SendMessageW() in ClientRpcChannelBuffer_SendReceive() for STAs.

[Marvin]

Hi,

It looks like your patch introduced the new failures shown below.
Please investigate and fix them before resubmitting your patch.
If they are not new, fixing them anyway would help a lot. Otherwise
please ask for the known failures list to be updated.

The tests also ran into some preexisting test failures. If you know how
to fix them that would be helpful. See the TestBot job for the details:

The full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=126926

Your paranoid android.

=== debian11 (32 bit report) ===

ole32:
marshal.c:2999: Test failed: COM call during processing of sent message should return RPC_E_CANTCALLOUT_ININPUTSYNCCALL instead of 0x00000000