Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Writer Crashed When 0 Pages Selected for Export as PDF|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||CLOSED FIXED||QA Contact:|
|Priority:||P3||CC:||alisa_ps, arielch, Armin.Le.Grand, fanyuzhen, issues, jsc, rainerbielefeld_ooo_qa, sayalee03, vaddepal|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
Description bahughes 2012-09-27 04:23:05 UTC
System Configuration: Win 7 Ultimate SP1 x64 Ram - 8 GB Processor - Intel Core 2 Duo 2.6/2.6 GHz Steps to Reproduce 1) Open a Writer .odt document containing at least one page of content. 2) Go to File > Export as PDF and select the Pages radio button. 3) Enter 0 and click on Export. Expected Behavior: Error handling would have rejected an input of 0 pages as invalid. Actual Behavior: Save As dialog opened allowing me to enter a file name, when I clicked save a Write Error message box popped. Text of the message box: "Error saving the document sample: (I had named it sample22) Write Error. The file could not be written." When I responded to the dialog and closed Writer the OpenOffice.org Document Recovery dialog opened and the Files to be recovered list was empty. My apologize if this is a duplicate. I searched for a similar bug for 20 minutes before submitting.
Comment 1 bahughes 2012-09-27 04:46:53 UTC
I achieved the same result by entering 'a' in the Pages field.
Comment 2 alisa_ps 2012-09-29 23:02:16 UTC
I followed the steps given above and was able to successfully replicate the bug on Windows 7 Ultimate SP1. The same bug was also achieved when the number entered in 'Pages' text box exceeded the actual number of pages of content in the document. I got the same end result: The error message appeared only after user was prompted to save the file. After closing Writer, the Document Recovery dialog opened with recovery list being empty.
Comment 3 VEERASEKHAR ADDEPALLI 2012-09-30 22:05:00 UTC
Tested on Macintosh & Windows 7 I was able to replicate the bug successfully in both Macintosh & Windows 7 Steps that I followed: 1. Create a .odt document. 2. Select the "Export as pdf" option in File menu 3. Select the pages radio button. 4. Enter 0 or any invalid input like 'a', '%Yu',67ui8, etc., 5. a. Actual Behavior in Windows 7: Open office crashes diplaying a dialog box saying "Due to an unexpected error, Openoffice.org crashed". The dialog box does not close after clicking the close button. It will be closed only if we hit ok button. b. Actual Behavior in Macintosh: Open office crashes displaying a dialog box saying "Openoffice.org quit unexpectedly" 6.Exptected Behavior : Input validation procedures should not accept the invalid input like 0 'a' '%Yu' 67ui8 etc., The exceptions on the invalid input should be handled properly by showing the proper messages to the end user. 7. However, in both the cases, the .odt file could not be exported to pdf though it asks to enter the filename to be saved as when we are using this feature.
Comment 4 sayalee 2012-09-30 23:57:10 UTC
I tested the bug on Windows 7 professional and Mac OS and could successfully replicate the bug on both. The steps I followed are-- 1) Open a Writer document containing at least one page of content. 2) Go to File -->Export as PDF. 3) Select the Pages radio button. 4) Enter 0 and click on Export. The same result is observed when a non-digit character like a, %,$,#,( etc or a number exceeding the existing number of pages is given. Result expected: Invalid inputs such as 0, a, number exceeding the actual number of pages should be rejected and a appropriate warning message should be displayed to the user. Actual result: (i) In the Windows OS, a 'save as' dialog box opened, prompting me to enter a filename. When I clicked the 'save' button, an error message popped up saying,"Error saving the document MyFile: Write Error. The file could not be written". After closing the writer,a document recovery dialog box appeared with the Files to be recovered list empty. (ii)In the Mac OS,Open office crashed suddenly displaying an error message "Openoffice.org quit unexpectedly".
Comment 5 Ariel Constenla-Haile 2012-10-01 00:37:17 UTC
Confirming Setting CRASH keyword
Comment 6 Ariel Constenla-Haile 2012-10-01 00:45:32 UTC
Created attachment 79698 [details] GDB backtrace Steps to get that backtrace: - Create a new Writer document - File - Export as PDF... - On the PDF export dialog, tab "General", "Range", "Pages", enter 0 - Export - After selecting the file name, you get a "Write error" error box - close the Writer document (via the menu bar close or File - Close, it's the same) - Crash
Comment 7 Ariel Constenla-Haile 2012-10-01 00:52:55 UTC
Adjusting platform (reproducible on Win, Linux, MacOS) Adjusting component: cannot reproduce in Draw or Calc
Comment 8 Armin Le Grand 2013-06-06 13:47:33 UTC
ALG: Taking a look. Could reproduce the crash, taking a look what happens with this given zero (main/filter as it seems).
Comment 9 Armin Le Grand 2013-06-06 15:12:25 UTC
ALG: Problem seems to be that '0' in PageRange is an invalid data entry (Pages start at 1). The string is parsed late (inside the export filter) and the missing part seems to be a adequate reaction on a wrong PageRange definition.
Comment 10 Armin Le Grand 2013-06-06 15:49:58 UTC
ALG: Tried to avoid calling ExportSelection in PDFExport::Export when no pages are to be exported (there is already an if(nPageCount)). This does not work since in PDFExport::ExportSelection in the rRenderable->render call which triggers SwXTextDocument::render the SwRenderData is deleted early at the end. When *not* calling ExportSelection this cleanup is not done and the SwRenderData stays until the writer doc is closed. At that time it *will* access data which is long gone (that exists only during PDF export). That cleanup has to be done in PDFExport::Export after the ExportSelection calls at xRenderable, not in the xRenderable implementation (which is a writer document), but how...?
Comment 11 Armin Le Grand 2013-06-07 09:54:16 UTC
ALG: The cleanup has to be done; thus calling render in some way is even necessary when nothing is to be rendered. To trigger this, somehow in the render call information has to be given for this special operation. There are various alternatives to do that, checked with giving a special value as nRenderer and reacting on it in the render implementation (SwXTextDocument::render) by doing the needed cleanup. This works (I will add example patch), but is a hack itself. To change the writer implementation to work more clean if getRendererCount is used but render is not is not an alternative, too complex to do. There is another alternative; try to watch for the ViewShell which is deleted already and causes the crash to be deleted and do the cleanup there. CHecking this...
Comment 12 Armin Le Grand 2013-06-07 09:57:01 UTC
Created attachment 80791 [details] ALG: A possible solution, but a hack
Comment 13 Armin Le Grand 2013-06-07 11:06:06 UTC
ALG: Got a solution to react on ViewShell change. In SwDocShell::SetView it is possible to access the SwXTextDocument. Added a method there (CleanupViewShellDependentIssues) which does the needed cleanup. Tested, works well. This means that cleanup when not calling render is no longer required, but postponed to changes of the model. Due to this I also checked exporting twice (with the error) and mixes of printing and exporting in the same document while it's open, looks good. Adaping a little bit, adding comments...
Comment 14 Armin Le Grand 2013-06-07 11:34:31 UTC
ALG: Changed function name to 'ReactOnViewShellChange', checked again, works well. Changes now only happen on the writer side what is a much better solution than in filter; changes there would have risked that any other implementation of XRenderable might react differently on the cleanup-render-call. Preparing checkin...
Comment 15 Armin Le Grand 2013-06-07 11:36:09 UTC
ALG: Okay, comitted, done.
Comment 16 SVN Robot 2013-06-07 11:46:28 UTC
"alg" committed SVN revision 1490593 into trunk: i121125 Secured release of remembered data (ViewShell) in PDFExport when noth...
Comment 17 jsc 2013-07-03 08:22:12 UTC
grant showstopper flag to get a clear status, already fixed
Comment 18 fanyuzhen 2013-07-09 10:21:41 UTC
It's verified fixed in revision 1499347, no crash is seen.
Comment 19 Oliver-Rainer Wittmann 2013-08-16 13:29:01 UTC
(In reply to Armin Le Grand from comment #11) > ALG: The cleanup has to be done; thus calling render in some way is even > necessary when nothing is to be rendered. To trigger this, somehow in the > render call information has to be given for this special operation. There > are various alternatives to do that, checked with giving a special value as > nRenderer and reacting on it in the render implementation > (SwXTextDocument::render) by doing the needed cleanup. This works (I will > add example patch), but is a hack itself. To change the writer > implementation to work more clean if getRendererCount is used but render is > not is not an alternative, too complex to do. > There is another alternative; try to watch for the ViewShell which is > deleted already and causes the crash to be deleted and do the cleanup there. > CHecking this... XRenderable is also used for printing and the printing already passed a certain option - namely <bLastPage> - the last <render(..)> call to trigger the clean up. Such a <render(..)> call is also made in the printing routines when no regular <render(..)> is made.
Comment 20 Oliver-Rainer Wittmann 2013-08-16 13:33:25 UTC
(In reply to SVN Robot from comment #16) > "alg" committed SVN revision 1490593 into trunk: > i121125 Secured release of remembered data (ViewShell) in PDFExport when > noth... These changes solve the crash, but the clean up of the rendering data has also an important purpose by using the holding a reference to a <ViewShell> instance. This purpose is the restore the original view options which were changed for the PDF export resp. the printing. Thus, the current clean up comes too late. Example: - new text document - insert page number field - switch view option to view field names (Menu - View - Field Names) - export to PDF - Pages = "bad input" --> no crash after closing the text document --> view option to view field names is not restored.
Comment 21 Rainer Bielefeld 2013-10-09 04:22:58 UTC
(a) Is ok with "AOO 4.0.1 – German UI / German locale [Rev. 1524958 2013-09-20 11:40:29]" on German WIN7 Home Premium (64bit)", “historic” 4.0 User Profile used for all predecessor versions and : I see the error message, but OOo does no longer crash when I close Writer after test. (b) same good result with "AOO 4.0.0 Final – German UI / German locale [AOO400m3(Build:9702) - Rev. 1503704 2013-07-16 14:54:56 (Di, 16 Jul 2013)]" on German German WIN7 Home Premium (64bit)", Common 4.0-dev User Profile (b) Is reproducible with AOo 3.4.1 and with Server installation of "AOO 4.0.0-Dev – English UI / German locale [AOO400m1(Build:9700) – Rev.1476029 ((2013-04-26))]" on German WIN7 Home Premium (64bit)", own separate user profile (d) So I would like to select correct target 4.0.0, but because of crippled Target Milestone selector (Bug Bug 123063) no useful info can be left. Latest confirmation for AOO 4.0.0-dev, but because of incomplete LCo selector (Bug 123063) no correct information can be left.
Comment 22 Rainer Bielefeld 2013-10-11 05:21:15 UTC
VERIFIED with "AOO 4.1.0-Dev – English UI / German locale - [AOO410m1(Build:9750) - Rev. 1530680 - 2013-10-11]" on German WIN7 Home Premium (64bit)", own separate user profile (please see "Bug 123444 - CRASH when choosing "Selection" radio button on "Print" dialog" #c8