[Bug 14065] WordPerfect Office X3: Application crash after change of window focus

[wine-bugs at winehq.org]

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





--- Comment #2 from Forester <pbronline-wine at 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 ?


-- 
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.