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)
file too large for attachment you can download it here http://oooconv.free.fr/aTrier/libro/CR_CM_120625.odt
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
NOT reproduced in libro3.3.2 linux after a first raise, memory globally remains stable over modify/saving cycles
*** Bug 53120 has been marked as a duplicate of this bug. ***
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"
Regression does appear in oldest version of bibisect-3.5.tar.lzma and must be older
under Linux x86_64 (Ubuntu 12.04) LibrO 3.4.6.2 --> memory is eaten !!! (so, comment #5 seems only applying on winXP ???)
NOT repoducible on Windows 7 x64 SP1 with Version 3.6.1.2 (Build ID: e29a214)
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.
[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>
[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
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.
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).
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?
@taestom <http://wiki.documentfoundation.org/BugReport_Details#Version> Please do not touch the dashboard ;-)
Hello, I have tested version 3.6.4 with Windows 7 SP1, and bug is still there.
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
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.
(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.
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.
(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
(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
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?
(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
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.
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 :-)
Created attachment 80794 [details] large memory leak
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."
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 ...
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
Created attachment 83601 [details] Windows 7 Taskmanager
Created attachment 83602 [details] Windows 7 Ressource (monitor) [Filesave, the other was fileopen)
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....
[Somehow the bug got assigned to me
Sorry for the mail spam, changing component
@Florian which version did you use for your latest tests? 4.0.4, 4.1.0 or 4.2alpha?
I do think master.... (Sorry, sometimes forgetting) But can you confirm the improvement using fodt..?
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.
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.
(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.
still reproducible with version 4.2.1.0.0+ under Ubuntu 13.10 x86-64 Best regards. JBF
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.
Moving to mab4.1 (Bug 60270) because: - 4.0 reached EOL (End Of Life) - bug confirmed in later version
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
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
I wonder if http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-2&id=4eea91d7a9a90a40839925909c1173b4469e0eb4 fixes this too ?
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
Indeed no memory leak anymore in LO 4.2 and LO 4.3 with the bugdoc. Thank you very much :-) Best regards. JBF