[Bug 53014] HICON leak in CopyImage causes TheBat! to crash after a while

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=53014

--- Comment #2 from jswinebz at kanargh.org.uk ---
Created attachment 72494
  --> https://bugs.winehq.org/attachment.cgi?id=72494
Fix UNICODE_STRING handling in NtUserGetIconInfo

Well, the module filename truncation is due to NtUserGetIconInfo messing up its
string handling. Firstly, UNICODE_STRING *definitely* counts in bytes, always,
never characters. Secondly, when calculating the length of the returned
res_name, it stores the value in the module name's buffer, overwriting the
module name length it just calculated above. Since resource names tend to be
shortish strings, this will usually have the effect of truncating the returned
path.

That gets us into the correct path within CopyImage to do COPYFROMRESOURCE
properly, but doesn't solve the deadlock.

Turning on +module too, at the point of the crash we get:

05fc:trace:cursor:CopyImage hnd=000000000006016C, type=1, desiredx=16,
desiredy=16, flags=4000
[...]
05fc:trace:cursor:CURSORICON_Load 0000000000400000, L"Z_BAT_1", 16x16, depth
32, fCursor 0, flags 0x4000
05fc:trace:module:FindResourceExW 0000000000400000 #000e L"Z_BAT_1" 0000
05fc:trace:module:LoadResource 0000000000400000 00000000026B7AE0
05fc:trace:cursor:CURSORICON_FindBestIcon entry 0: 32 x 32, 4 bpp
05fc:trace:cursor:CURSORICON_FindBestIcon entry 1: 16 x 16, 4 bpp
05fc:trace:cursor:CURSORICON_FindBestIcon entry 2: 16 x 16, 8 bpp
05fc:trace:module:FindResourceExW 0000000000400000 #0003 #0023 0000
05fc:trace:module:LoadResource 0000000000400000 00000000026B5F90
07dc:trace:module:LdrShutdownThread ()
07dc:trace:module:MODULE_InitDLL (00000000043E0000
L"libegl.dll",THREAD_DETACH,0000000000000000) - CALL
07dc:trace:module:MODULE_InitDLL
(00000000043E0000,THREAD_DETACH,0000000000000000) - RETURN 1
[...]
05fc:trace:module:LdrGetDllFullName module 0000000000400000, name
0000000002EEE1D0.
[...]
07dc:trace:module:MODULE_InitDLL (00000003AFD00000
L"imm32.dll",THREAD_DETACH,0000000000000000) - CALL
07dc:trace:module:MODULE_InitDLL
(00000003AFD00000,THREAD_DETACH,0000000000000000) - RETURN 1
07dc:trace:module:MODULE_InitDLL (000000023D820000
L"user32.dll",THREAD_DETACH,0000000000000000) - CALL
05fc:err:sync:RtlpWaitForCriticalSection section 0000000170067640
"dlls/ntdll/loader.c: loader_section" wait timed out in thread 05fc, blocked by
07dc, retrying (60 sec)
07e0:err:sync:RtlpWaitForCriticalSection section 0000000170067640
"dlls/ntdll/loader.c: loader_section" wait timed out in thread 07e0, blocked by
07dc, retrying (60 sec)
05fc:trace:module:FindResourceExW 0000000000400000 #0006 #0ffd 0000
05fc:trace:module:LoadResource 0000000000400000 00000000026B6330
05fc:trace:module:FindResourceExW 000000007B600000 #0006 #0101 0809
05fc:trace:module:LoadResource 000000007B600000 000000007B65DD10
[...]
05fc:trace:module:FindResourceExW 000000023D820000 #0005 L"MSGBOX" 0009
05fc:trace:module:LoadResource 000000023D820000 000000023D8DD020
05fc:err:system:user_check_not_lock BUG: holding USER lock
m Files\The Bat!\thebat64.exe: dlls/win32u/sysparams.c:385:
user_check_not_lock: Assertion `0' failed.
[...thread 5fc crashing due to deadlock detection...]

So a different thread has apparently exited, and so we called user32's DllMain
for THREAD_DETACH, but DllMain never returned. This thread exit happened while
we were in the middle of executing CURSORICON_Load - presumably this takes a
lock for either user32 or NtUser which DllMain also needs to proceed. But
calling DllMain takes the loader_section lock, which CURSORICON_Load will also
require when it calls LdrGetDllFullName to fill in its own cursoricon_object
structure...

Deadlock!

(Since the DllMain locking behaviour is prehistoric, this must be a change in
the way user32 handles THREAD_DETACH between 6.21 and 7.5...)

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.