http://bugs.winehq.org/show_bug.cgi?id=22091
Sam Revitch sam.revitch@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sam.revitch@gmail.com
--- Comment #21 from Sam Revitch sam.revitch@gmail.com 2010-10-13 00:28:13 CDT --- I was able to reproduce this problem using Wine 1.3.4 on Gentoo Linux.
The Setup.exe program appears to extract a set of archives using functionality provided by nsisunrar2.dll. For each archive, it appears to call LoadLibrary() on nsisunrar2.dll, some exported functions to process the archive, and FreeLibrary() on completion.
The nsisunrar2.dll library uses SetWindowsHookEx() to set up a WH_GETMESSAGE hook on the secondary thread created by Setup.exe. When Setup.exe finishes its first archive and makes its call to FreeLibrary() for nsisunrar2.dll, it seems to reliably happen while the hook callback is executing on the secondary thread. Despite this, the unload and DLL_PROCESS_DETACH handling proceed. Somewhere in that mess, an ABBA deadlock seems to occur with the secondary thread waiting in GetModuleHandle() for the loader_section, and the primary thread waiting in WaitForMultipleObjects() called somewhere within nsisunrar2.dll's hook function, presumably a synchronization mechanism private to that module.
I would present a stack trace, but nsisunrar2.dll does not save frame pointers, and winedbg can't make heads or tails out of its frames. The conclusions above were reached by looking for raw symbols on the stack.
The apparent cause is that wine's handling of hook functions does not wrap their invocations with references preventing the host DLL from being unloaded. I wrote a test program that deterministically triggers this race, and have confirmed that no race can be triggered on WinXP SP3, but wine-1.3.4 will cause the program to crash.
With this problem resolved, the installation will inconsistently crash just before finishing, also due to a deadlock on the loader_section. Disabling DLL unloading altogether seems to work around this deadlock, so it would appear to be caused by another unexpected reference count underflow. This issue might deserve its own bug.