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