Bug 52433 - MEMORY LEAK: large .odt (with many big StarViewMetafiles) leading to 200Mb leak each save.
Summary: MEMORY LEAK: large .odt (with many big StarViewMetafiles) leading to 200Mb le...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
3.5.0 RC1
Hardware: All All
: highest critical
Assignee: Caolán McNamara
URL:
Whiteboard: bibisected35 bibisected35older
Keywords: regression
: 53120 (view as bug list)
Depends on:
Blocks: mab4.2
  Show dependency treegraph
 
Reported: 2012-07-24 08:42 UTC by Laurent Godard
Modified: 2014-05-30 10:26 UTC (History)
14 users (show)

See Also:
Crash report or crash signature:


Attachments
large memory leak (1.75 MB, application/x-gzip)
2013-06-13 19:50 UTC, Michael Meeks
Details
Windows 7 Taskmanager (13.21 KB, image/png)
2013-08-04 07:15 UTC, Florian Reisinger
Details
Windows 7 Ressource (monitor) [Filesave, the other was fileopen) (10.04 KB, image/png)
2013-08-04 07:24 UTC, Florian Reisinger
Details
NO Memory leak --> FILESAVE (2.47 KB, image/png)
2013-08-04 07:30 UTC, Florian Reisinger
Details
new valgrind trace (1.01 MB, text/x-log)
2013-09-18 06:00 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Laurent Godard 2012-07-24 08:42:15 UTC
here is a writer-memory-eater-file (10 Mb) that lead to crash . 

each time i save, it eats memory (some hundreds of Mb) without giving it back.

 after some save cycles, Libro crashes due to memory exhaustion on winXP

 this is related to images included in the file. removing the images, problem disappears. The images come from impress slides copy-paste

reproduced on 3.5.5 (winxp & linux) and 3.7-master (linux)
Comment 1 Laurent Godard 2012-07-24 09:03:43 UTC
file too large for attachment

you can download it here
http://oooconv.free.fr/aTrier/libro/CR_CM_120625.odt
Comment 2 Jean-Baptiste Faure 2012-07-24 10:13:38 UTC
Reproducible under Linux x86_64 (Ubuntu 11.10) with LO 3.5.5.3 and LO 3.6.1.0+ (Build ID: 10ae81a)
No crash for me but obviously memory leak. The only mean to recover the RAM is to close LO. Closing the file does not release the RAM.

Best regards. JBF
Comment 3 Laurent Godard 2012-07-24 12:33:20 UTC
NOT reproduced in libro3.3.2 linux
after a first raise, memory globally remains stable over modify/saving cycles
Comment 4 Julien Nabet 2012-08-12 14:10:41 UTC
*** Bug 53120 has been marked as a duplicate of this bug. ***
Comment 5 Laurent Godard 2012-08-21 08:22:57 UTC
here are more tests regarding older versions, on winXP (VM)

3.4.6rc2 --> OK, no problem, the memory is not eaten
3.5.0rc1 --> PROBLEM, the memory is eaten at each "save file"
Comment 6 Laurent Godard 2012-08-24 15:58:19 UTC
Regression does appear in oldest version of bibisect-3.5.tar.lzma and must be older
Comment 7 Laurent Godard 2012-08-28 08:41:16 UTC
under Linux x86_64 (Ubuntu 12.04)
LibrO 3.4.6.2 --> memory is eaten !!! (so, comment #5 seems only applying on winXP ???)
Comment 8 Florian Reisinger 2012-09-07 14:03:17 UTC
NOT repoducible on Windows 7 x64 SP1 with Version 3.6.1.2 (Build ID: e29a214)
Comment 9 taestom 2012-11-01 21:52:33 UTC
I have a small .odt file, less than 40 kB. In it, however, I embed 50 or so 10 megapixel jpegs as LINK. For each image there is a table. The image is inside a table cell. Each table has its own frame.

When I save that file, or when autosave runs, or when I export it to pdf, writer crashes. In process explorer I can see that prior to the crash it touches all the images. Writers working set goes up continually and eventually, above 1.5GB, writer crashes. For each image writer uses about 25MB when saving, about 5MB prior to saving and about 140MB with the text file only. With 50 images this leads to 140+50*(25+5)=1.64GB.
I run Windows XP and, as 32 bit system, it does not like this. 64 bit systems may not be affected.

Even it there is no chrash, the saving times are annoying.

If the working set does not reach 1.5GB, the memory is sometimes given back, sometimes not, depending on the odt file used.

I have reports that OO3.0 leaves the image files alone, as it should. And saves are fast as they should when only links are used.
Comment 10 Rainer Bielefeld Retired 2012-11-08 06:12:48 UTC
[Reproducible] with Server installation (own profile) of "LibreOffice  3.5.6.2  German UI/Locale [Build-ID: e0fbe70-5879838-a0745b0-0cd1158-638b327] on German WIN7 Home Premium (64bit) 

[Reproducible]  with Server installation of Master "LibO-dev 3.5.0  – WIN7 Home Premium (64bit) English UI 
[(Build ID:d337f79-a24c961-2865670-9752b71-7f8fd43
	2fdd60d-fd28b6a-fd7bf20-aa369cb-28da3fb
	6a9633a-931d089-ecd263f-c9b55e9-b31b807
	82ff335-599f7e9-bc6a545-1926fdf)]"  from (July 2011)

Each 'Save - as' under new name increases memory consumption of soffice.bin additional 400MB (or so), when required memory becomes bigger than 1.5GB LibO Crashes on my PC

I will nominate this one as HardHack on <http://wiki.documentfoundation.org/HardHacks>
Comment 11 michel 2012-11-08 10:25:16 UTC
[Reproducible] with LibreOffice 3.5.7 on Ubuntu 12.04 32 bits; at each save, memory increase (after having saved, memory used is larger than before saving) but no crash.

[Reproducible] with LibreOffice 3.5.7 on Windows 7 Home Premium 64 bits; at each save, memory increase, crash of LibreOffice when memory used by soffice.bin over 1.5 GBytes.

[Reproducible] with LibreOffice 3.6.3 on Windows 7 Home Premium 64 bits; at each save, memory increase, crash of LibreOffice when memory used by soffice.bin is over 1.5 GBytes.

Bug was not existing with LibreOffice 3.4.6 on Windows 7 Home Premium 64 bits; bug doesn't exist with Apache OpenOffice 3.4.1 on Windows 7 Home Premium 64 bits.

It seems related to a recent regression, appeared in LibreOffice 3.5.x
Comment 12 Michael Meeks 2012-11-08 16:08:53 UTC
Oh no - this is a disasterous image management is utterly shambolic issue.
Checkout bug#47148 - this is a really nasty issue that will take several man weeks to fix properly - a very very hard hack sadly.

No doubt it could be 'fixed' in a trivial way - but that would risk loosing images shared with other documents I suspect.
Comment 13 michel 2012-11-08 17:24:43 UTC
It seems there are two problems:
- a bad and buggy images management inherited from OpenOffice and StarOffice that would probably require weeks of man work to be fixed.
- this bug, a memory leak that appears when you save a file with images from writer; this bug is NOT inherited from OpenOffice and has appeared in LibreOffice 3.5.1, and is present on any version of LibreOffice 3.5 and 3.6, and was not in 3.4.x.

Solving this bug could be probably done by analyzing what changes have been done in the images management between LibreOffice 3.4.6 and 3.5.1, identifying the regression, and correct the bug.

This might not take weeks.

Note that for several users, like me, LibreOffice is no longer usable (I have switched to Apache OpenOffice, waiting for this bug to be corrected).
Comment 14 taestom 2012-11-09 22:34:22 UTC
For 3.6.2.2 on Windows XP and a quite small odt file containing large images as embedded links, 
1. I cannot confirm a memory leak when saving, the memory comes back, sometimes it takes a while
2. I can confirm a crash when saving with lots of images as the memory goes beyond 1,5 GB. Writer opens all the images in succession and does not seem to close them and giving back the memory before opening further (as seen in Process Explorer). Same when exporting to pdf.

So there may be two unrelated problems. As to the second one: writer shouldn't even touch the images when saving as odt. Hard to imagine that this is hard to fix. Any hint as to a similar bug or should I file this as a new one?
Comment 15 Rainer Bielefeld Retired 2012-11-10 06:20:32 UTC
@taestom
<http://wiki.documentfoundation.org/BugReport_Details#Version>
Please do not touch the dashboard ;-)
Comment 16 michel 2012-12-18 17:55:36 UTC
Hello,
I have tested version 3.6.4 with Windows 7 SP1, and bug is still there.
Comment 17 Joel Madero 2013-02-13 21:43:23 UTC
Moving this to 3.6 MAB because 3.5 is at the of its cycle and we will be closing the meta tracker for 3.5 MAB.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Confirmed On:
Version 4.1.0.0.alpha0+ (Build ID: 871712ad62bb01359c29713a148a5673e26df1a)
Bodhi Linux
Comment 18 Owen Genat (retired) 2013-04-16 02:45:05 UTC
Is it possible that the memory leak in the example file (comment #1) is related to the use of StarView Metafile (SVM) graphics (88 of the 89 included pictures)? The sample also includes MS Word text styles e.g., in styles.xml there are entries like:

<style:style style:name="WW-Titre1234567891011121314151617181920212223242526272829303132333435363738" style:family="paragraph">

<style:style style:name="WW8Num5z0" style:family="paragraph">

A cleaner test file might narrow down the source of the problem.
Comment 19 michel 2013-04-18 13:07:31 UTC
(In reply to comment #18)
> Is it possible that the memory leak in the example file (comment #1) is
> related to the use of StarView Metafile (SVM) graphics (88 of the 89
> included pictures)? The sample also includes MS Word text styles e.g., in
> styles.xml there are entries like:
> 
> <style:style
> style:name="WW-
> Titre1234567891011121314151617181920212223242526272829303132333435363738"
> style:family="paragraph">
> 
> <style:style style:name="WW8Num5z0" style:family="paragraph">
> 
> A cleaner test file might narrow down the source of the problem.

Hello,

I can see the memory leak with a writer file with jpeg pictures (several tens), and no SVM one. 

Regards.
Comment 20 Héctor Luaces Novo 2013-06-11 22:07:15 UTC
Hello,

The bug persists on LibreOffice 4.0.3 on Windows 7 Pro x64 and Ubuntu 13.04.

Is there any workaround or alternative to get around this bug? I can't use my odt files.
Comment 21 michel 2013-06-12 11:38:58 UTC
(In reply to comment #20)
> Hello,
> 
> The bug persists on LibreOffice 4.0.3 on Windows 7 Pro x64 and Ubuntu 13.04.
> 
> Is there any workaround or alternative to get around this bug? I can't use
> my odt files.

Hello,

There are very few workarounds:
- to shut down LibreOffice periodically to recover the RAM,before Writer crashes,
- to use some system util programs to periodically recover RAM (there are some available for Windows),
- to use OpenOffice while the bug is not corrected in LibreOffice (it is what I did, I switched to OpenOffice 3.4.1; when saving a writer file with images the RAM used by soffice increases considerably, like in LibreOffice, but unlike in LibreOffice there is no memory leak: after having saved the file the amount of RAM used by soffice goes back to the initial value).

Regards,

M. Nallino
Comment 22 michel 2013-06-12 11:43:07 UTC
(In reply to comment #21)
> (In reply to comment #20)
> > Hello,
> > 
> > The bug persists on LibreOffice 4.0.3 on Windows 7 Pro x64 and Ubuntu 13.04.
> > 
> > Is there any workaround or alternative to get around this bug? I can't use
> > my odt files.
> 
> Hello,
> 
> There are very few workarounds:
> - to shut down LibreOffice periodically to recover the RAM,before Writer
> crashes,
> - to use some system util programs to periodically recover RAM (there are
> some available for Windows),
> - to use OpenOffice while the bug is not corrected in LibreOffice (it is
> what I did, I switched to OpenOffice 3.4.1; when saving a writer file with
> images the RAM used by soffice increases considerably, like in LibreOffice,
> but unlike in LibreOffice there is no memory leak: after having saved the
> file the amount of RAM used by soffice goes back to the initial value).
> 
> Regards,
> 
> M. Nallino

Here is a detailed workaround in order to free RAM on Windows:
Download "sysinternals utilities" suite from Microsoft download site.
Use "RAMMap.exe" jointly with LibreOffice (keep RAMMap running).
After each file save, in RAMMap go to "Empty" menu, click on "Empty Working Sets". This forces LibreOffice to release its memory ("soffice.bin" used RAM goes down to 20 MB after an "Empty Working Sets").

M. Nallino
Comment 23 Héctor Luaces Novo 2013-06-12 19:07:45 UTC
Thanks for the replies, I'll try that, but that's just half of the problem. The other half is that the memory comspumtion skyrockets on saving files with lot of images, is there a workaround for this? or is this another bug?
Comment 24 michel 2013-06-13 11:52:09 UTC
(In reply to comment #23)
> Thanks for the replies, I'll try that, but that's just half of the problem.
> The other half is that the memory comspumtion skyrockets on saving files
> with lot of images, is there a workaround for this? or is this another bug?

Hello,

Unfortunately there are two distinct problems:

- OpenOffice up to 3.4.1 or LibreOffice up to 3.4.6 have a very bad management of images: you may copy / paste them in Writer, or just add an html link, but in all cases, when you save your file, the RAM used by the process "soffice" reaches very high values (I have a file with 127 images and, when I save it, the RAM used by soffice reaches some 1.4GB!).

- LibreOffice, all 3.5.x, 3.6.x, 4.0.x versions, has another problem: one part of the amount of the RAM is not released after having saved; next time, RAM will increase from an higher bottom value and will reach an higher maximum value, and some part will not be released, and so on; after a few saves, Writer will crash.

There is no workaround for the 1st problem (high RAM consumption), you just need to have a lot of RAM in your computer to avoid an extensive use of page swapping (that slows down your computer). I have used OpenOffice and LibreOffice on computers having just 1GB RAM, I have just to say that you have time to do plenty of things when Writer is in save mode. (Now my computer has 16GB of RAM, and it is no longer a problem!)

For the memory leak, workarounds are to use OpenOffice 3.4.1, or LibreOffice 3.4.6, or, if you still want / need to use more recent versions of LibreOffice to free the RAM periodically by shutting down LibreOffice or by using an external memory management program.

I still don't know when / if this bug will be corrected in LibreOffice, and I just hope that the bug will not appear in the next announced release of OpenOffice, the 4.0 (it might be there, if it is a library related bug, with a new release using an updated set of libraries).

In that case, I would stay with OpenOffice 3.4.1 or even switch to MS Office 2013 ;-)!

Of course, I would be very glad to use a reliable version of LibreOffice 3.6.x or 4.0.x, since it offers lots of functions, but, at this time, I can't.

Best regards,

M. Nallino
Comment 25 Joel Madero 2013-06-13 17:53:49 UTC
not sure why regression isn't on this one:

comment 5 says it worked in 3.4 and is broken in 3.5, adding regression because of this.
Comment 26 Michael Meeks 2013-06-13 19:46:51 UTC
Well this bug is quite extreme. I had assumed that if people genuinely wanted a fix - they might help out development by providing a leak trace from eg. valgrind. That takes a few minutes to run - and makes our life -incredibly- easier. If there was a trace on this bug months ago when I first saw it - I would have done some development work on it ( JFYI ).

Here is how to build that - I would appreciate it if this ended up on some QA page:

valgrind --leak-check=full --show-reachable=yes --num-callers=50 ./soffice.bin /opt/libreoffice/tmp/CR_CM_120625.odt 2>&1 | tee /tmp/val-leak.txt

Then attach /tmp/val-leak.txt for analysis. The app runs 80x slower - this is a pain in the backside - but it's just as much of a pain for me as you :-)
Comment 27 Michael Meeks 2013-06-13 19:50:40 UTC
Created attachment 80794 [details]
large memory leak
Comment 28 Michael Meeks 2013-06-13 19:54:58 UTC
As expected it is the hideous horror of the image cache, and the horrible UNO mess around it, and the lack of sane lifecycle management, caching, well - anything really around images. The big trace is:

==13133== 205,217,708 bytes in 141 blocks are possibly lost in loss record 9,694 of 9,694
==13133==    at 0x402ACB9: operator new[](unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==13133==    by 0x9C84DC9: X11SalBitmap::Create(Size const&, unsigned short, BitmapPalette const&) (salbmp.cxx:701)
==13133==    by 0x52AD0F3: ImpBitmap::ImplCreate(Size const&, unsigned short, BitmapPalette const&) (impbmp.cxx:58)
==13133==    by 0x527D764: Bitmap::Bitmap(Size const&, unsigned short, BitmapPalette const*) (bitmap.cxx:125)
==13133==    by 0x526F497: Bitmap::ImplReadDIB(SvStream&, Bitmap&, unsigned long, unsigned char) (bitmap2.cxx:147)
==13133==    by 0x526F9EC: Bitmap::Read(SvStream&, unsigned char, unsigned char) (bitmap2.cxx:119)
==13133==    by 0x526FA5D: operator>>(SvStream&, Bitmap&) (bitmap2.cxx:94)
==13133==    by 0x52BE8D2: MetaBmpScaleAction::Read(SvStream&, ImplMetaReadData*) (metaact.cxx:1858)
==13133==    by 0x52C67DA: MetaAction::ReadMetaAction(SvStream&, ImplMetaReadData*) (metaact.cxx:227)
==13133==    by 0x529F4AB: operator>>(SvStream&, GDIMetaFile&) (gdimtf.cxx:2770)
==13133==    by 0x52B0528: operator>>(SvStream&, ImpGraphic&) (impgraph.cxx:1686)
==13133==    by 0x52A8511: operator>>(SvStream&, Graphic&) (graph.cxx:577)
==13133==    by 0x5234AEA: GraphicFilter::ImportGraphic(Graphic&, String const&, SvStream&, unsigned short, unsigned short*, unsigned long, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>*, WMF_EXTERNALHEADER*) (graphicfilter.cxx:1560)
==13133==    by 0x5234C76: GraphicFilter::ImportGraphic(Graphic&, String const&, SvStream&, unsigned short, unsigned short*, unsigned long, WMF_EXTERNALHEADER*) (graphicfilter.cxx:1326)
==13133==    by 0x11F955B8: SwGrfNode::ImportGraphic(SvStream&) (ndgrf.cxx:452)
==13133==    by 0x11F96983: SwGrfNode::SwapGraphic(GraphicObject*) (ndgrf.cxx:1014)
==13133==    by 0x11F96A86: SwGrfNode::LinkStubSwapGraphic(void*, void*) (ndgrf.cxx:967)
==13133==    by 0x4BC827C: GraphicObject::GetSwapStream() const (link.hxx:123)
==13133==    by 0x4BC8CD0: GraphicObject::ImplAutoSwapIn() (grfmgr.cxx:203)
==13133==    by 0x4BC9450: GraphicObject::GetGraphic() const (grfmgr.cxx:732)
==13133==    by 0x11F953C4: SwGrfNode::onGraphicChanged() (ndgrf.hxx:131)
==13133==    by 0x11E65EE0: SwDoc::Insert(SwPaM const&, GraphicObject const&, SfxItemSet const*, SfxItemSet const*, SwFrmFmt*) (doc.cxx:1059)
==13133==    by 0x1211B955: SwXFrame::attachToRange(com::sun::star::uno::Reference<com::sun::star::text::XTextRange> const&) (unoframe.cxx:2281)
==13133==    by 0x1211CCE6: SwXFrame::attach(com::sun::star::uno::Reference<com::sun::star::text::XTextRange> const&) (unoframe.cxx:2469)
==13133==    by 0x1219198A: SwXText::insertTextContent(com::sun::star::uno::Reference<com::sun::star::text::XTextRange> const&, com::sun::star::uno::Reference<com::sun::star::text::XTextContent> const&, unsigned char) (unotext.cxx:617)
==13133==    by 0x10AC7ADB: XMLTextImportHelper::InsertTextContent(com::sun::star::uno::Reference<com::sun::star::text::XTextContent>&) (txtimp.cxx:1170)
==13133==    by 0x10AA5168: XMLTextFrameContext_Impl::Create(unsigned char) (XMLTextFrameContext.cxx:743)
==13133==    by 0x10AA69DC: XMLTextFrameContext_Impl::XMLTextFrameContext_Impl(SvXMLImport&, unsigned short, rtl::OUString const&, com::sun::star::uno::Reference<com::sun::star::xml::sax::XAttributeList> const&, com::sun::star::text::TextContentAnchorType, unsigned short, com::sun::star::uno::Reference<com::sun::star::xml::sax::XAttributeList> const&) (XMLTextFrameContext.cxx:1089)
==13133==    by 0x10AA6CFF: XMLTextFrameContext::CreateChildContext(unsigned short, rtl::OUString const&, com::sun::star::uno::Reference<com::sun::star::xml::sax::XAttributeList> const&) (XMLTextFrameContext.cxx:1507)
==13133==    by 0x109A74EE: SvXMLImport::startElement(rtl::OUString const&, com::sun::star::uno::Reference<com::sun::star::xml::sax::XAttributeList> const&) (xmlimp.cxx:682)
==13133==    by 0x10BE60F6: sax_expatwrap::SaxExpatParser_Impl::callbackStartElement(void*, char const*, char const**) (sax_expat.cxx:827)
==13133==    by 0x10BF14FD: doContent (xmlparse.c:2469)
==13133==    by 0x10BF1C04: contentProcessor (xmlparse.c:2105)
==13133==    by 0x10BF31FB: XML_ParseBuffer (xmlparse.c:1651)
==13133==    by 0x10BE67B6: sax_expatwrap::SaxExpatParser_Impl::parse() (sax_expat.cxx:765)
==13133==    by 0x10BE759E: sax_expatwrap::SaxExpatParser::parseStream(com::sun::star::xml::sax::InputSource const&) (sax_expat.cxx:553)
==13133==    by 0x1222D746: ReadThroughComponent(com::sun::star::uno::Reference<com::sun::star::io::XInputStream>, com::sun::star::uno::Reference<com::sun::star::lang::XComponent>, String const&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext>&, char const*, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&, rtl::OUString const&, bool, bool) (swxml.cxx:182)
==13133==    by 0x1222DED5: ReadThroughComponent(com::sun::star::uno::Reference<com::sun::star::embed::XStorage>, com::sun::star::uno::Reference<com::sun::star::lang::XComponent>, char const*, char const*, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext>&, char const*, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&, rtl::OUString const&, bool) (swxml.cxx:372)
==13133==    by 0x1222FB8B: XMLReader::Read(SwDoc&, String const&, SwPaM&, String const&) (swxml.cxx:921)
==13133==    by 0x121ACCBC: SwReader::Read(Reader const&) (shellio.cxx:177)
==13133==    by 0x1226ABDD: SwDocShell::Load(SfxMedium&) (docshini.cxx:532)
==13133==    by 0x47F443D: SfxObjectShell::LoadOwnFormat(SfxMedium&) (objstor.cxx:3048)
==13133==    by 0x47FE4BA: SfxObjectShell::DoLoad(SfxMedium*) (objstor.cxx:710)
==13133==    by 0x481F319: SfxBaseModel::load(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (sfxbasemodel.cxx:1887)
==13133==    by 0x486A612: SfxFrameLoader_Impl::load(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&) (frmload.cxx:597)
==13133==    by 0xF9F9540: framework::LoadEnv::impl_loadContent() (loadenv.cxx:1166)
==13133==    by 0xF9FA5CB: framework::LoadEnv::startLoading() (loadenv.cxx:400)
==13133==    by 0xF9B8343: framework::LoadDispatcher::impl_dispatch(com::sun::star::util::URL const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Reference<com::sun::star::frame::XDispatchResultListener> const&) (loaddispatcher.cxx:119)
==13133==    by 0xF9B86AE: framework::LoadDispatcher::dispatchWithReturnValue(com::sun::star::util::URL const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (loaddispatcher.cxx:65)
==13133==    by 0x447B535: comphelper::SynchronousDispatch::dispatch(com::sun::star::uno::Reference<com::sun::star::uno::XInterface> const&, rtl::OUString const&, rtl::OUString const&, long, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (synchronousdispatch.cxx:69)

Which is why this bug depends on bug#47148 - "image caching / management is utterly shambolic."
Comment 29 Michael Meeks 2013-06-13 20:01:55 UTC
I suspect the fix for:
https://bugs.freedesktop.org/show_bug.cgi?id=33393#c37

Is related to this - but then again, I don't believe we want to loose images on autosave in order to fix this leak ;-)

0389b77a3cbea09ddbae238d7934d4c6349a8d37

Did I mention - that the tracker: "image management is utterly shambolic" is there to track this important task ? it needs doing, no-one has done it, and volunteers are much appreciated: there is -so- much that is really really silly about our image management including the infamous "graphics cache" that ...
Comment 30 michel 2013-07-28 10:19:40 UTC
Hello,
It seems that Apache OpenOffice 4.0 has changed the way memory is managed. I have a large file (260 MB, 387 pages, 129 jpeg pictures). When I open it with OpenOffice 3.4.1, or with LibreOffice 3.6.6 (the latest version I have tested, under Windows 7), the memory used by "soffice.bin" is some 400 MB. When I open it with AOO 4.0, the memory used is some 950 MB.
When I save with AOO 3.4.1 or LO 3.6.6, memory used increases up to 1500 MB (and comes back to 400 MB with AOO 3.4.1, or 600 MB with LO 3.6.6 --> here is the memory leak).
However, when I save it with AOO 4.0, the memory used constantly decreases, down to some 90 MB. With future use (write / save) of AOO 4.0 memory stays in the range 90 - 125 MB, decreasing to 90 MB at each save.
It seems that there is a memory release mechanism that has been used in AOO 4.0.
The result is that both peak and average memory used is lower than with AOO 3.4.1 and that there is still no memory leak, unlike with LO 3.5x and further versions.
Maybe the way memory is managed by AOO 4.0 could be analysed, and used in a future release of LO?

Best regards, 
M. Nallino
Comment 31 Florian Reisinger 2013-08-04 07:15:17 UTC
Created attachment 83601 [details]
Windows 7 Taskmanager
Comment 32 Florian Reisinger 2013-08-04 07:24:02 UTC
Created attachment 83602 [details]
Windows 7 Ressource (monitor) [Filesave, the other was fileopen)
Comment 33 Florian Reisinger 2013-08-04 07:30:19 UTC
Created attachment 83603 [details]
NO Memory leak --> FILESAVE

Hi,

So I finished testing.
I got a memory leak on saving the file. When I used the format Flat ODT (fodt) I didn't get one. So this might help you and every developer trying to work on this bug.
The downside for you that this needs twice the place on your hard drive....
Comment 34 Florian Reisinger 2013-08-04 07:30:56 UTC
[Somehow the bug got assigned to me
Comment 35 Florian Reisinger 2013-08-04 07:32:22 UTC
Sorry for the mail spam, changing component
Comment 36 tommy27 2013-08-10 06:46:36 UTC
@Florian
which version did you use for your latest tests? 4.0.4, 4.1.0 or 4.2alpha?
Comment 37 Florian Reisinger 2013-08-11 18:12:40 UTC
I do think master.... (Sorry, sometimes forgetting)
But can you confirm the improvement using fodt..?
Comment 38 tommy27 2013-08-15 07:28:41 UTC
I confirm RAM-eating from test document in Comment 1 using LibO 4.0.4 on Win7 64bit.

I also confirm Florian's observations regarding .fodt saving... RAM-eating does not happen with the .fodt saved test document.

moving bug from mab3.6 list to mab4.0 list since 3.6.x is EOL.
Comment 39 Julien Nabet 2013-09-18 06:00:56 UTC
Created attachment 86038 [details]
new valgrind trace

On pc Debian x86-64 with master sources updated yesterday, I still reproduce the problem. I attached a new valgrind trace.
Comment 40 Björn Michaelsen 2014-01-17 09:58:29 UTC
(This is an automated message.)

Setting priority to highest as this is a 4.0 MAB. This is part of an effort to make the importance of MAB reflected in priority too.
Comment 41 Jean-Baptiste Faure 2014-01-18 17:32:03 UTC
still reproducible with version 4.2.1.0.0+ under Ubuntu 13.10 x86-64

Best regards. JBF
Comment 42 Marko Mahnič 2014-02-06 17:22:08 UTC
I can confirm a similar problem with metafiles in LibreOffice Version: 4.1.3.2 
Build ID: 410m0(Build:2) on Ubuntu 13.10.

For this test I created a file with 2 pages. Page 1 is covered with an imported 
SVG image. Page 2 is covered with an imported emf or wmf image.

When only the first page with the SVG is visible, the program works normally. 
On every redraw the program allocates approximately 2MB of memory which is 
released soon afterwards.

As soon as the emf/wmf image from page 2 becomes visible, the program starts 
allocating approximately 2MB on every redraw and this memory is never 
released. This soon consumes all the available memory and hangs the system with 
a lot processes going into "disk sleep" state, probably because LibreOffice is 
swapping objects in and out of memory.

If I make the wmf/emf image smaller, less memory is being lost.

This is what I think is going on: to render an embedded metafile a temporary 
raster buffer is allocated which is never released after the rendering is 
complete.
Comment 43 stragu 2014-02-12 08:19:20 UTC
Moving to mab4.1 (Bug 60270) because:
- 4.0 reached EOL (End Of Life)
- bug confirmed in later version
Comment 44 tommy27 2014-05-02 14:58:00 UTC
if you guys still reproduce this bug under 4.2.x please move it to the mab 4.2 list ( Bug 65675 ) since 4.1.x is END OF LIFE
Comment 45 Jean-Baptiste Faure 2014-05-02 17:21:00 UTC
Still reproducible for me with LibO 4.2.5.0.0+ under Ubuntu 14.04 x86-64

Moving to MAB 4.2 list.

Best regards. JBF
Comment 47 Caolán McNamara 2014-05-28 16:04:38 UTC
Yeah, reverting that fix locally, on each save the memory usage jumps, restore that fix and it remains stable. I'll call that fixed by http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-2&id=4eea91d7a9a90a40839925909c1173b4469e0eb4
Comment 48 Jean-Baptiste Faure 2014-05-30 10:26:56 UTC
Indeed no memory leak anymore in LO 4.2 and LO 4.3 with the bugdoc.

Thank you very much :-)

Best regards. JBF