http://bugs.winehq.org/show_bug.cgi?id=14065
--- Comment #2 from Forester pbronline-wine@yahoo.co.uk 2008-11-16 12:24:58 --- Re-examination of this bug suggests the crash is a direct result of mshtml.dll being unloaded.
Trace with Quattro Pro X3 with WINEDEBUG=+loaddll,+mshtml gives the following:
Start application ... lots of trace ending with:
trace:mshtml:nsURI_Release (0x1d5400) ref=0 trace:mshtml:nsWebBrowserChrome_Release (0x9c9068) ref=12 trace:mshtml:nsURI_Release (0x13a45c8) ref=5 trace:mshtml:nsURI_Release (0x13a45c8) ref=4 trace:mshtml:nsURI_Release (0x13a45c8) ref=3 trace:mshtml:nsURI_Release (0x13a45c8) ref=2
Switch window context to some other window; wait 60 seconds (it doesn't take that long but 60 s is certainly long enough); move cursor over Wine's Quattro Pro window and the following appears ...
trace:loaddll:free_modref Unloaded module L"C:\windows\system32\shdocvw.dll" : builtin trace:mshtml:DllCanUnloadNow () ref=0 trace:mshtml:close_gecko () trace:loaddll:free_modref Unloaded module L"C:\windows\system32\mshtml.dll" : builtin trace:loaddll:free_modref Unloaded module L"C:\windows\system32\urlmon.dll" : builtin fixme:shell:DllCanUnloadNow stub fixme:msimtf:DllCanUnloadNow ()
Click on the Wine window to give it focus and it crashes in call_window_proc() with a page fault on read from an address that does not correspond to a loaded module.
When DllCanUnloadNow() in dlls/mshtml/main.c is changed to always return S_FALSE (just to see what happens) close_gecko() is not called, mshtml is not unloaded and the application does not crash.
It would seem (to someone who knows nothing of what mshtml does) that unloading the module while there are still references to objects (with vtables) that the module is responsible for is probably not a good idea.
The return value from DllCanUnloadNow() is normally controlled by the value of the module global variable module_ref, which is incremented and decremented by macros named LOCK_MODULE and UNLOCK_MODULE. These macros are used in protocol.c and htmldoc.c pretty much as one (such as myself) might expect.
However, these appear to be the exception rather than the rule - mshtml is a big module and there appear to be lots of other places where one (such as myself) might expect to find LOCK_MODULE and UNLOCK_MODULE but doesn't.
As one expected, when LOCK_MODULE/UNLOCK_MODULE are used with nsWebBrowserChrome in nsemed,c (just to see what happens), one finds that mshtml is not loaded and the application does not crash.
Have I stumbled on the real problem or is my analysis way off base ?