[Bug 22091] Dragon Age Awakening setup crashes with ntdll error

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=22091

Sam Revitch <sam.revitch at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sam.revitch at gmail.com

--- Comment #21 from Sam Revitch <sam.revitch at 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.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
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.