I have a large document file that consistently crashes Writer. I have tested it with all available versions of Open Office Writer and LibreOffice Writer, including the latest 4.0 Beta. I use a Mac under Snow Leopard, but it exhibits the same behavior with a PC running Vista/Win7 as well. The file is a large manuscript with lots of inserts, text boxes, photos, etc. I have obfuscated the file a bit and placed it on my public Dropbox folder at: https://dl.dropbox.com/u/11336636/Gregory%20Family%20Origins%20-%20Submission.odt Warning, it is a big file, about 100 MB. The problem is similar to, and likely related to a problem I previously reported as bug 56963 for LibreOffice Writer, but has some subtle differences and seems to be related to a specific page in the document which contains numerous pictures. Where 56963 crashed only on the Update ALL function, this lockup/crash occurs when simply displaying the afflicted page. To reproduce the problem, open the file in Writer. Open the Navigator, open "Graphics" and select the "Elias Snedegar Tombstone" and navigate to the page containing that image. The page contains a total of 9 small photos with captions. All that is necessary is to move around the page a bit, maybe select a caption frame, etc. It is not necessary to actually edit or modify anything, all that needs happen is for Writer to move around the page a bit. Within a few seconds it will lock up and become unresponsive. I have left it sitting overnight and it has never recovered. It will usually crash if left a few hours. I have opened the XML and examined the area both by eye and with XMLlint and cannot identify any XML error that might be provoking the problem. As far as I can tell, the provocation is related merely to the number of pictures on the page, although I am experimenting with recreating the issue with a smaller document to verify that... This problem has completely stopped my project as I am unable to find a workaround that will allow me to continue to edit the file.
This could be the same problem as bug 52569 and/or bug 59837.
(In reply to comment #0) > To reproduce the problem, open the file in Writer. Open the Navigator, open > "Graphics" and select the "Elias Snedegar Tombstone" and navigate to the > page containing that image. The page contains a total of 9 small photos > with captions. All that is necessary is to move around the page a bit, > maybe select a caption frame, etc. It is not necessary to actually edit or > modify anything, all that needs happen is for Writer to move around the page > a bit. Within a few seconds it will lock up and become unresponsive. I > have left it sitting overnight and it has never recovered. It will usually > crash if left a few hours. Does this happen in a new document with this page only? If yes, could you attach it?
Since posting the original report, I have been working to reduce the document to the trouble-making component. I cannot edit the document enough to extract the troublesome component, but I did considerably reduce the size of the file considerably, and removed the pictures, proving they are not the issue. I split the document via making a master document split at headings, and reduced the troublesome part to a single chapter, and managed to prove that it is not the images, but the chapter they are in that is the issue... I have placed that chapter on Dropbox as https://dl.dropbox.com/u/11336636/Gregory%20Family%20Origins12y.odt Even so, I cannot further isolate the area of the problem since it crashes every time I try to touch it, or edit it. Simply opening the file is enough to lock it up. I let it set overnight and it did not recover. I finally forced it to quit, although usually if left long enough it will crash. Near the end of the chapter there is a map image with a large, complex caption. I am suspicious that this is the problem, as it is the single thing that is unusual. I managed to copy that image and place it in a new document, and the new one did not crash. I do not consider that entirely conclusive however. I was unable to obfuscate this chapter file, as I cannot edit it at all. Nathan
(In reply to comment #1) > This could be the same problem as bug 52569 and/or bug 59837. Possibly, but I cannot be sure. As I described below, I copied the suspect image to a new document and the new one did not crash. I will experiment with opening the ODT file and deleting the suspect image and see what effect that has...
Ok, here's something freaky.... Continuing to mess with the document I managed to create a new version that does NOT crash Writer. It is, more-or-less, identical to the first, with the same images, same text, and so on. I opened content.xml and attempted to do a diff to figure out what is different, but it found way too many differences for me to make sense of. So I am presenting the second version for consideration, perhaps someone with more XML knowledge or better tools can spot the key difference. https://dl.dropbox.com/u/11336636/Gregory%20Family%20Origins12z.odt I am not precisely certain what action created this variant, but perhaps it will be a helpful clue. I will keep trying to determine which action I took that made the key difference, but meanwhile with both files available perhaps someone else can see what is going on.
Thanks for reporting. I can confirm this behavior using LibreOffice Version 4.1.0.0.alpha0+ (Build ID: 1a3c90a292c7fc9060604151de9dc51eecf5b6a) (build today) with Linux Mint 14 x64. I clicked on the "Elias Snedegar Tombstone" in the navigator, I scrolled a bit, click again, select some things (click around in the document) and then I got a crash (following my terminal -> Exited with code '139'). I'll upload my terminal output (it's not from the beginning). Following [1] I mark this bug as 'Critical medium'. Kind regards, Joren [1]
(In reply to comment #6) > [1] https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg
Created attachment 74292 [details] terminal log of LO 4.1 master
I may have isolated the cause of the problem to a single textbox. If you open Navigator and go to textboxes and scroll to the one titled "1873 Cholera Epidemic", doing ANYTHING with that text box, including simply deleting it, locks up Writer. I managed to delete the box in a test copy, and that seemed to clear the problem. Several "Update All" actions worked flawlessly once the offending textbox is deleted. This textbox is odd, and unique, because it covers a whole page. I suspect that is the trigger for this bad behavior, as one would not normally expect a textbox to fill a page. I tried pasting the offending textbox into a new document but could not re-create the problem that way. It seems as if it must be a fairly complex document, with indices and more. Now I am trying to find an otherwise non-destructive way to delete it from my "production" copy. I desperately need to find a way to move forward with my project as this problem has me in chaos at the moment. Thanks, Nathan
I recreated the problem again in a new document that was neither huge nor complex. Clearly the problem is provoked by inserting a textbox (i.e. as a Sidebar) that is overly large, especially if this textbox is centered in the page text area. It appears that if a textbox exceeds about 50% of the page area, the problem appears. In the latest case, I split the sidebar into two smaller textboxes and the lockup ceased. The issue seems to be large textboxes centered on the page.
The file is no more available in dropbox. Any update with recent LO version? (last stable release is 4.3.1)
I have eliminated the problematical text box and photos from the current version of the document, and have been working with the current "Fresh" 4.3.1.2 without major problems. However, when I saw your comment, I went back to an older version and opened it in the "Fresh" version, scrolled down to the "1873 Cholera" textbox, and was immediately greeted with the "spinning beach ball", which has been going on for quite a while now. I am waiting to see it crash, and have little doubt it will do so. Based on this, I believe the problem has NOT been fixed. The culprit seems to be any textbox that covers a significant part of a page. I am placing the offending document on a cloud folder so you can try it yourself. Since it is a big document, I can't leave it there long, but feel free to download and let me know when you are done with it. You can get it at : https://app.box.com/s/b1pyu6zojb2vjj14qk2n Nathan
Thank you for your feedback, I retrieved the file, I'll do some tests after my daytime work.
On pc Debian x86-64 with master sources updated yesterday, I noticed these kind of logs: warn:sw.core:4499:1:sw/source/core/txtnode/ndhints.cxx:268: HintsCheck: Portion inconsistency. This can be temporarily ok during undo operations warn:legacy.tools:4499:9:linguistic/source/gciterator.cxx:165: lcl_SkipWhiteSpaces: illegal arguments warn:sw:4499:9:sw/inc/swrect.hxx:296: SVRect() without Width or Height warn:legacy.osl:4499:1:sw/source/core/layout/sortedobjs.cxx:202: <SwSortedObjs::Insert()> - already contains object warn:legacy.osl:4499:1:sw/source/core/layout/calcmove.cxx:1926: Only a warning for task 108824:/n<SwCntntFrm::_WouldFit(..) - follow not valid! warn:legacy.osl:4499:1:sw/source/core/layout/flylay.cxx:948: ::CalcClipRect(..) - frame, vertical position is oriented at, is missing . warn:legacy.osl:4499:1:sw/source/core/layout/flylay.cxx:446: <SwFlyFreeFrm::CheckClip(..)> - fly frame has negative height now. warn:legacy.osl:4499:1:sw/source/core/layout/anchoredobject.cxx:581: <SwAnchoredObject::GetObjRectWithSpaces> - cache for object rectangle inclusive spaces marked as valid, but it couldn't be. Missing invalidation of cache. Please inform OD. warn:legacy.osl:4499:1:sw/source/core/layout/flowfrm.cxx:2377: <SwFlowFrm::MoveBwd(..)> - layout loop control for layout action <Move Backward> applied!
Created attachment 106223 [details] random bt On pc Debian x86-64 with master sources updated today, I attached a random bt once the number of pages increases quickly (infinitely?)
Michael: another layout management problem? Is there a metabug or a bug to put in See Also?
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.1 or preferably 5.0.2.2 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-10-14
None of the files are up anymore. Were they all so big that our current 10MB limit is still too low?
Please feel free to reopen a bug if attachment is added or uploaded. In this case, it would be nice to test master LO version from http://dev-builds.libreoffice.org/daily/master/.