http://bugs.winehq.org/show_bug.cgi?id=14065
Summary: WordPerfect Office X3: Application crash after change of window focus Product: Wine Version: 1.0.0 Platform: PC URL: http://www.corel.com/servlet/Satellite?pagename=uk/Proce ssLayout&lc=en&ppg=CorelCorp/Trials/Login&pid=1153321202 705&cid=1153321202184 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: pbronline-wine@yahoo.co.uk
Created an attachment (id=14287) --> (http://bugs.winehq.org/attachment.cgi?id=14287) Wine output at point of crash
Affects WordPerfect and Quattro Pro but Presentations appears to be immune.
Start application from command line without start.exe. Click OK or whatever until application is ready for work. Wait a couple of minutes. Switch to another window. Trace shows
fixme:shell:DllCanUnloadNow stub fixme:msimtf:DllCanUnloadNow () fixme:hlink:DllCanUnloadNow
Switch back to application window and application crashes. You may get
wine: Unhandled page fault on read access to 0x7db5c600 at address 0x7db5c600 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x7db5c600 in 32-bit code (0x7db5c600).
or CARM (Corel Application Recovery [sic] Manager) may start at which point it and the application's window are frozen and soon the OS offers to terminate wine as it is no longer responding.
Which you get seems to depend on whether you install IE6 or not.
http://bugs.winehq.org/show_bug.cgi?id=14065
Forester pbronline-wine@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pbronline-wine@yahoo.co.uk
http://bugs.winehq.org/show_bug.cgi?id=14065
Forester pbronline-wine@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Alias|Forester |
--- Comment #1 from Forester pbronline-wine@yahoo.co.uk 2008-06-25 13:33:54 --- Remarks re install of IE6 are a red herring. You get the unhandled page fault with builtin VB6 dlls and CARM with the native VB6 dlls.
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 ?
http://bugs.winehq.org/show_bug.cgi?id=14065
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #3 from Dan Kegel dank@kegel.com 2008-12-01 09:41:08 --- Looks like the real problem. See http://www.winehq.org/pipermail/wine-devel/2008-December/070846.html
http://bugs.winehq.org/show_bug.cgi?id=14065
Forester pbronline-wine@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|pbronline-wine@yahoo.co.uk | Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #4 from Forester pbronline-wine@yahoo.co.uk 2009-01-08 12:26:11 --- This issue appear resolved in Wine 1.1.11 since mshtml.dll was changed to never unload from memory.
http://bugs.winehq.org/show_bug.cgi?id=14065
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #5 from Alexandre Julliard julliard@winehq.org 2009-01-16 10:38:40 --- Closing bugs fixed in 1.1.13.
-
wine-bugs＠winehq.org