https://bugs.winehq.org/show_bug.cgi?id=39779
Jane Li lixjcn@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lixjcn@yahoo.com
--- Comment #3 from Jane Li lixjcn@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?