[Bug 39779] Deadlock due to lock order inversion: LoaderSection and Win16Mutex

[wine-bugs at winehq.org]

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

Jane Li <lixjcn at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lixjcn at yahoo.com

--- Comment #3 from Jane Li <lixjcn at yahoo.com> ---
Created attachment 53174
  --> https://bugs.winehq.org/attachment.cgi?id=53174
new deadlock bt info

Test result on wine-1.8-rc4 shows major part of the issue is fixed. After
checking codes, I understood the reason, it is exactly fixed(partially) by the
commited you listed.
In wine, the lock sequence is : 
   loaderSection
   win16mutex (bottom level)
So whenever loaderSection is being requested, the thread needs to be sure
win16mutex is not in its hand. 
The commit you listed is to release win16mutex before calling LoadLibraryA
function to ensure this.


However, another deadlock is detected in my newest test(on wine-1.8-rc4), it's
due to win16mutex is not released before calling FreeLibrary which will also
finally request loaderSection lock.
See attached for the deadlock call stack information.

In general, all calls to LoadLibraryA or FreeLibrary in
krnl386.exe16/ne_module.c should be protected by ReleaseThunkLock and
RestoreThunkLock. 
I searched the file codes, all LoadLibrary calls are protected, but several
FreeLibrary calls are not. The deadlock detected in my newest test is one of
them.

Would you confirm if it's a bug and consider a fix for "krnl386.exe: Release
the Win16 lock when FREEING a 32-bit dll?

-- 
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.