http://bugs.winehq.org/show_bug.cgi?id=25873
Summary: PAF5 now crashes is using the help viewer and clicking four chapter titles Product: Wine Version: 1.3.12 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: rmriches@ieee.org
Created an attachment (id=32972) --> (http://bugs.winehq.org/attachment.cgi?id=32972) stdout/stderr from application run that crashed
This is a regression in a downloadable application. I'm sorry, but I cannot afford the hours of time it takes to run a regression test to pinpoint the commit that introduced the problem. (I am working on building a new computer that should be much faster, so maybe in a few months...)
This may be related to bug #23416, in which the help window contents pane was mostly if not entirely blank. In subsequent comments, some later versions than 1.2-rc4 brought back display of some text, but other problems remained. Comment #17 to bug #23416 indicated a need for "overhauling how urlmon does CreateURLMoniker or ..."
The symptoms are similar to bug #17227, introduced in 1.1.12 and fixed in 1.1.28.
The crash is very reproducible. For a simplified, repeatable test sequence, I installed PAF5 into a fresh prefix area. I used the PAF5AllLangs.exe installer. I selected English as the installation language. I selected to install the "International Unicode Font". I deselected viewing the 'getting started document'. Installation finished with no apparent problem.
When running the application, I chose to create a new file of name z9, z8, z7, or etc. I clicked on 'cancel' on the two dialogs that followed. I clicked on the yellow question mark in the menu bar to bring up the help viewer. In the left-hand pane of the help window, I clicked on the first four chapter titles in turn. When I clicked on the fourth one, a dialog appeared that said Wine had detected a problem and needed to close. I clicked the 'close' button.
http://bugs.winehq.org/show_bug.cgi?id=25873
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ehoover@mines.edu, | |jacek@codeweavers.com
--- Comment #1 from Erich Hoover ehoover@mines.edu 2011-01-24 22:14:53 CST --- (In reply to comment #0)
... This is a regression in a downloadable application. I'm sorry, but I cannot afford the hours of time it takes to run a regression test to pinpoint the commit that introduced the problem. (I am working on building a new computer that should be much faster, so maybe in a few months...)
Such a regression test would be very difficult for you to do unless you've been paying close attention to urlmon, it's changed quite a bit recently (you need to work around the "spaces in filenames" issue). Since I'm already familiar with that issue, and I was concerned that this problem might be something that I had overlooked, I tracked down this regression for you:
---- 0b046c94ac52b05983ac8cae7e2aef0bfec771b3 is the first bad commit commit 0b046c94ac52b05983ac8cae7e2aef0bfec771b3 Author: Jacek Caban jacek@codeweavers.com Date: Thu Dec 2 13:50:02 2010 +0100
mshtml: Added ActiveX control creation implementation.
:040000 040000 a032a5b136adc58bc4941977b7f0421cf9ca24d2 2c308a0db12bfa8873e59cbe382d1c59652f1aca M dlls ----
I looked into this a little bit and the issue can be "fixed" by removing the call to nsIDOMWindow_Release in npplugin.c:get_elem_window. However, this solution is almost certainly incorrect - the real problem is likely that there is a missing AddRef somewhere. I poked around a bit to see if I could find the missing call, but I didn't see anything suspicious. So, I dug a little deeper and found that (in gecko) the nsIWebProgress has no GetDOMWindow method. Instead, in that position in the nsIWebProgress vtable it has a read-only DOMWindow attribute. If I had to guess I'd say that this (nsio.c:get_channel_window) is where our missing AddRef call should be (or an extra Release, depending on how you look at it).
http://bugs.winehq.org/show_bug.cgi?id=25873
--- Comment #2 from Robert Riches rmriches@ieee.org 2011-01-24 22:31:21 CST --- Thank you very much for running the regression and doing the analysis. I hope that might help lead a developer to a fix.
In a case or two in the past, I have run a regression. In those cases, it wasn't difficult, just time consuming. My current, seven-year-old computer takes an hour to compile Wine for each step of the process.
http://bugs.winehq.org/show_bug.cgi?id=25873
--- Comment #3 from Robert Riches rmriches@ieee.org 2011-03-20 17:36:34 CDT --- On application PAF5, with Wine 1.3.16 and Wine Gecko 1.2.0, the symptom of a crash after clicking on four chapter titles appears to have gone away. I did get a Gecko exception and eventually a Wine hang after canceling a print and following some hyperlinks. I would guess it would be most appropriate to close this report as fixed (unless there is some reason to keep it open) and file new reports for the new issues if/when they can be reliably reproduced.
http://bugs.winehq.org/show_bug.cgi?id=25873
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #4 from Dmitry Timoshkov dmitry@codeweavers.com 2011-03-21 03:45:52 CDT --- Reported fixed.
http://bugs.winehq.org/show_bug.cgi?id=25873
--- Comment #5 from Erich Hoover ehoover@mines.edu 2011-03-21 10:56:12 CDT --- (In reply to comment #3)
... I did get a Gecko exception and eventually a Wine hang after canceling a print and following some hyperlinks. ...
Please open a new bug and CC me on it, I added the printing support so it's likely my fault.
http://bugs.winehq.org/show_bug.cgi?id=25873
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #6 from Alexandre Julliard julliard@winehq.org 2011-04-01 12:41:02 CDT --- Closing bugs fixed in 1.3.17.