We need to make sure all (important) cleanup is finished when we exit DllMain, otherwise we might already unload krnl386 and deadlock Since we can't have a synchronous DestroyWindow, use an extra message
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52511 Signed-off-by: Fabian Maurer dark.shadow4@web.de
Code flow is like follows:
- DOSVM_Exit -> RtlExitUserThread -> LdrShutdownThread - acquire loader lock - send DLL_THREAD_DETACH to imm32 - - calls DestroyWindow on its window - - WM_DESTROY is handled asynchonously! - send DLL_THREAD_DETACH to krnl386.exe - - TASK_ExitTask - - try get win16 lock, is blocked by ime32
meanwhile, at ime32
- handles WM_DESTROY - already have win16 lock from user32 - __wine_ime_wnd_proc (WM_DESTROY) -> imm_couninit_thread -> CoRevokeInitializeSpy - LdrGetProcedureAddress (want CoRevokeInitializeSpy) - try get loader_lock, is blocked
Solution is to wait in ime32 DllMain until the cleanup as happened, aka CoRevokeInitializeSpy has finished.
-- v7: imm32: Prevent deadlock on unload
From: Fabian Maurer dark.shadow4@web.de
ole32 is delay loaded, which can cause race conditions against krnl386.exe when unloading. This is because imm32 tries to get the loader lock while holding the win16 mutex, and kernel386 does the opposite.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52511 Signed-off-by: Fabian Maurer dark.shadow4@web.de --- dlls/imm32/imm.c | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/dlls/imm32/imm.c b/dlls/imm32/imm.c index 780d544c0e9..d58376048f4 100644 --- a/dlls/imm32/imm.c +++ b/dlls/imm32/imm.c @@ -80,6 +80,9 @@ typedef struct _tagImmHkl{ DWORD (WINAPI *pImeGetImeMenuItems)(HIMC, DWORD, DWORD, IMEMENUITEMINFOW *, IMEMENUITEMINFOW *, DWORD); } ImmHkl;
+static HRESULT (WINAPI *pCoRevokeInitializeSpy)(ULARGE_INTEGER cookie); +static void (WINAPI *pCoUninitialize)(void); + typedef struct tagInputContextData { HIMC handle; @@ -249,7 +252,7 @@ static void imm_couninit_thread(BOOL cleanup)
if (cleanup && spy->cookie.QuadPart) { - CoRevokeInitializeSpy(spy->cookie); + pCoRevokeInitializeSpy(spy->cookie); spy->cookie.QuadPart = 0; }
@@ -261,7 +264,7 @@ static void imm_couninit_thread(BOOL cleanup) { spy->apt_flags &= ~IMM_APT_CREATED; if (spy->apt_flags & IMM_APT_CAN_FREE) - CoUninitialize(); + pCoUninitialize(); } if (cleanup) spy->apt_flags = 0; @@ -359,13 +362,28 @@ static const IInitializeSpyVtbl InitializeSpyVtbl = InitializeSpy_PostUninitialize, };
+static BOOL WINAPI init_ole32_funcs( INIT_ONCE *once, void *param, void **context ) +{ + HMODULE module_ole32 = GetModuleHandleA("ole32"); + pCoRevokeInitializeSpy = (void*)GetProcAddress(module_ole32, "CoRevokeInitializeSpy"); + pCoUninitialize = (void*)GetProcAddress(module_ole32, "CoUninitialize"); + return pCoRevokeInitializeSpy && pCoUninitialize; +} + static void imm_coinit_thread(void) { struct coinit_spy *spy; HRESULT hr; + static INIT_ONCE init_ole32_once = INIT_ONCE_STATIC_INIT;
TRACE("implicit COM initialization\n");
+ if (!InitOnceExecuteOnce(&init_ole32_once, init_ole32_funcs, NULL, NULL)) + { + ERR("Initialization failed\n"); + return; + } + if (!(spy = get_thread_coinit_spy())) { if (!(spy = HeapAlloc(GetProcessHeap(), 0, sizeof(*spy)))) return;
On Tue Nov 22 17:50:02 2022 +0000, Fabian Maurer wrote:
changed this line in [version 7 of the diff](/wine/wine/-/merge_requests/1456/diffs?diff_id=20331&start_sha=1b9600e4a1dda99d454eebf8d882300b805def0c#e1636e55e7589edf6f062150e93e6b31ab259317_83_83)
Fixed
On Tue Nov 22 12:41:13 2022 +0000, Piotr Caban wrote:
Please use e.g. InitOnceExecuteOnce to initialize the variables. In theory, one thread may set pCoRevokeInitializeSpy, second thread may assume at this point that pCoUninitialize is already set while it's not.
Fixed
Piotr Caban (@piotr) commented about dlls/imm32/imm.c:
InitializeSpy_PostUninitialize,
};
+static BOOL WINAPI init_ole32_funcs( INIT_ONCE *once, void *param, void **context ) +{
- HMODULE module_ole32 = GetModuleHandleA("ole32");
GetModuleHandleA will work after first call to ole32. Please move the initialization after CoInitializeEx call.