Apache OpenOffice (AOO) Bugzilla – Issue 124522
Memory leak opening OOo 3.2 .ODF in newer releases.
Last modified: 2014-04-10 14:57:21 UTC
When opening a certain .odf document containing text, index, cross references images and curve plots copy/pasted from .ods spreadsheet newer versions of openoffice/libreoffice freezes while claiming memory until physical limits are reached. Document and spreadsheet were created entirely using OOo3.2. When opening the .odt and .ods documents in OOo3.2 everything is completely normal. The issue I have reproduced with various versions of OpenOffice and LibreOffice (3.4, 4.0, 4.1) and OS WinXPSP3, Win7, Linux Mint (Ubuntu based) so I assume this may actually relate to a possible error in OOo3.2 I have tried to migrate the document using the .sxw format but with the exact same result, and export to .doc or .docx file type can not be done without loss of formatting information (especially page setup, headers/footers). What can I do to migrate such document to newer versions of OpenOffice - or am I trapped with using version 3.2? Thanks for helping and for taking this issue seriously.
First we would need the document you are talking about, could you please add it to this task as bugdoc?
Unfortunately I can not share she document in public since the information therein does not as such belong to me but to my employer. If you can instruct me on e.g. setting up a log file or something similar I will be happy to do so and supply such information.
We need a bugdoc to locally reproduce a defect. Could you please try either to ask your employer if you can use it or alternatively evtl. try to strip it (remove stuff, change text) and check if the effect still happens?
Thanks for the answer. I understand the need for a bugdoc. I will try to remove dissect the documents and see if I can identify which part gives the trouble.
Created attachment 83021 [details] Test docoment
I installed 4.1_Beta (DA) on a PC with generous amounts of RAM, and after some minutes of (Not responding) status while claiming RAM the document finally opened. When saving with 4.1_Beta I can still open with 3.2. While isolating different entities to see if any is misbehavin' I have come across some oddity with integerated graphic plot pasted directly from a 3.2 generated ods sheet. The legend shifts without reason. Enter the data table editor and apply legends to the columns (e.g. f1, f2 and f3) save and close document. What I see is that on next open the legends have changed: f3 will be labeled f2, f2 will be f1 and f1 will be nameless. When I open the document in 3.2 the legends are stable without this shift. This behavior may or may not be relevant to the original issue but it does indicate a leak of some kind.
I installed 4.1_Beta (DA) on a PC with generous amounts of RAM, and after some minutes of (Not responding) status while claiming RAM the document finally opened. When saving with 4.1_Beta I can still open with 3.2. While isolating different entities to see if any is misbehavin' I have come across some oddity with integerated graphic plot pasted directly from a 3.2 generated ods sheet. The legend shifts without reason. Enter the data table editor and apply legends to the columns (e.g. f1, f2 and f3) save and close document. What I see is that on next open the legends have changed: f3 will be labeled f2, f2 will be f1 and f1 will be nameless. When I open the document in 3.2 the legends are stable without this shift. This behavior may or may not be relevant to the original issue but it does indicate a leak of some kind. See attached test document.
(In reply to t_p_andersen from comment #7) > This behavior may or may not be relevant to the original issue but it does > indicate a leak of some kind. Thank you for the ongoing work on this issue. Your Test document opens fine but exposes the bug you described, so I opened the new Issue 124544 for it. If you got more information about the original document, please add it there. We still need a sample exposing the difficulties opening a OO.o 3.2 file. Maybe the build-in macro ChangeAllChars (in OO Macros/Gimmicks/ChangeAllChars) helps a bit.
Created attachment 83028 [details] Isolated issue Using simple trial and error I seemingly got the problematic part of the document isolated. See attached file. It is an object made using entirely using OOo3.2 Calc. So the issue may relate to calc rather than writer (as initially filed) since I can not identyfi wether the problem lies in the object it in the handling of the object within writer 3.4 and onwards.
thank you, that object looks like the culprit tested on Windows Vista 32bit 3GB RAM, AOO 4.1 Beta tried to open 5 times: 3 x crashed with "bad allocation" 2 x opened: - huge memory consumption (~1GB) while opening - went down to 119MB once and 222MB the next time need someone with a dev build to take a look @t_p_andersen you have the same problems opening the .ods files saved with OO.o 3.2? it would be easier to debug if we had sample .ods generated with 3.2 not sure whether this is a calc or chart problem, I leave it at writer for now
Created attachment 83029 [details] scalc object See requested file as attanchment 3. Object copied directly from the original 3.2 ods and saved in OO3.2. Open file -> right click object -> copy => problem. Claims much memory and CPU when handled in newer releases. Indicates that this is actually relating to calc rather than writer.
(In reply to t_p_andersen from comment #11) > See requested file as attanchment 3. Object copied directly from the > original 3.2 ods and saved in OO3.2. Open file -> right click object -> copy > => problem. Claims much memory and CPU when handled in newer releases. > Indicates that this is actually relating to calc rather than writer. Just tested: Opening the file -> Save in LibreOffice 3.5.7.2 -> close -> Open newly saved file => Normal behaviour when doing the above sequence.
Seeing that this relates to calc rather than writer, I have changed the product to calc for this issue.
Created attachment 83148 [details] spreadsheet and text document Hello again. After giving AOO 3.4.1 a chance I seem to realise that there actually exist an issue of interoperability between graphs generated in ods and inserted by ^C/^V or equivalent into an odt document. See attached documents. Open .ods Mark and copy the graph to buffer Open .odt and insert buffered object No data, no curve