Issue 124522

Summary: Memory leak opening OOo 3.2 .ODF in newer releases.
Product: General Reporter: t_p_andersen
Component: chartAssignee: AOO issues mailing list <issues>
Status: CONFIRMED --- QA Contact:
Severity: Major    
Priority: P3 CC: Armin.Le.Grand, j.nitschke, t_p_andersen
Version: 3.4.1Keywords: crash, needhelp
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Attachments:
Description Flags
Test docoment
none
Isolated issue
none
scalc object
none
spreadsheet and text document none

Description t_p_andersen 2014-03-26 16:09: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.
Comment 1 Armin Le Grand 2014-03-26 16:13:41 UTC
First we would need the document you are talking about, could you please add it to this task as bugdoc?
Comment 2 t_p_andersen 2014-03-26 21:12:00 UTC
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.
Comment 3 Armin Le Grand 2014-03-27 10:10:12 UTC
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?
Comment 4 t_p_andersen 2014-03-27 10:33:28 UTC
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.
Comment 5 t_p_andersen 2014-03-28 12:33:48 UTC
Created attachment 83021 [details]
Test docoment
Comment 6 t_p_andersen 2014-03-28 12:34:55 UTC
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.
Comment 7 t_p_andersen 2014-03-28 12:36:42 UTC
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.
Comment 8 j.nitschke 2014-03-28 14:12:25 UTC
(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.
Comment 9 t_p_andersen 2014-03-29 15:30:35 UTC
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.
Comment 10 j.nitschke 2014-03-29 16:25:48 UTC
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
Comment 11 t_p_andersen 2014-03-29 19:46:03 UTC
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.
Comment 12 t_p_andersen 2014-03-29 19:54:28 UTC
(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.
Comment 13 t_p_andersen 2014-03-29 22:56:52 UTC
Seeing that this relates to calc rather than writer, I have changed the product to calc for this issue.
Comment 14 t_p_andersen 2014-04-09 09:57:53 UTC
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