correction of summary.
Consequence of this bug : data loss when you can't save your file.

possible duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=38507

I haven't looked into it but sounds similar.

Created attachment 48343 [details]
another test document

It might be related to charts. I have created another sample document with two charts. It opens new temp files every time I go down or up the page.

The temp files are binary files starting with the text "VCLMTF". I think that it is a meta file describing the chart picture. I guess that it draws the chart from the beginning everytime it appears on the screen. It does not reuse and and does not close pictures that are not longer visible.

I do not see it with 3.4.0, so it a regression added in this bug fix release :-(

(In reply to comment #4)
> I do not see it with 3.4.0, so it a regression added in this bug fix release
> :-(

Something has been changed between 3.4.0 and 3.4.1 in the updating of a chart when data used to define this chart are modified. In 3.4.0 when you modify the value of a data, the chart is not updated automatically. It is in 3.4.1 rc1.

Best regards. JBF

I built the latest libreoffice-3-4 which shows the problem, then I downgraded -only- the 'sc' module to libreoffice-3-4-0 and the problem is gone.

Ergo at least the exacerbating cause of the issue is in the 'calc' repository (which includes chart2 of course) between libreoffice-3-4-0 and libreoffice-3-4-1. Hopefully that narrows it a little.

I didn't like this patch at the time it was reviewed on the list ;-> so I was suspicious from the outset that this was it, and ... bingo :-)

If I add / and/or remove just this one commit:

commit 70af08e849a93d56915b7abe14537facf1022a6a
Author: Cédric Bosdonnat <cedric.bosdonnat.ooo@free.fr>
Date:   Wed May 18 12:04:28 2011 +0200

    fdo#36688: Fixed undisplayed calc page and header / footer borders
    
    When displaying the page, header and footer borders, calc uses a fake
    ScDocument with no drawing page. Create a new SdrPage if none can be
    fetched from the ScDocument to create the primitive processor.
    
    Signed-off-by: Kohei Yoshida <kyoshida@novell.com>

diff --git a/sc/source/ui/view/output.cxx b/sc/source/ui/view/output.cxx
index f37a2c8..22b5d24 100644
--- a/sc/source/ui/view/output.cxx
+++ b/sc/source/ui/view/output.cxx
@@ -52,6 +52,7 @@
 #include <basegfx/matrix/b2dhommatrix.hxx>
 #include <svx/sdr/contact/objectcontacttools.hxx>
 #include <svx/unoapi.hxx>
+#include <svx/svdpage.hxx>
 
 #include "output.hxx"
 #include "document.hxx"
@@ -1634,17 +1635,19 @@ void ScOutputData::DrawRotatedFrame( const Color* pForceColor )
 
 drawinglayer::processor2d::BaseProcessor2D* ScOutputData::CreateProcessor2D( )
 {
+    SdrModel aModel;
+    SdrPage aSdrPage( aModel );
+
     ScDrawLayer* pDrawLayer = pDoc->GetDrawLayer();
-    if (!pDrawLayer)
-        return NULL;
+    if ( pDrawLayer )
+        aSdrPage = *pDrawLayer->GetPage( static_cast< sal_uInt16 >( nTab ) );
 
     basegfx::B2DRange aViewRange;
-    SdrPage *pDrawPage = pDrawLayer->GetPage( static_cast< sal_uInt16 >( nTab ) );
     const drawinglayer::geometry::ViewInformation2D aNewViewInfos(
...

Then the problem appears and/or goes away.

Creating that new SdrModel that new SdrPage and what we then do with it always seemed highly suspect to me :-) Of course, this prolly points to an underlying leak anyway - but we provoke it regularly here.

Cedric - your patch ...

*** Bug 38507 has been marked as a duplicate of this bug. ***

I think I had the problem with 3.4.0 as well - that is probably why I installed 3.4.1rc1 ??

Will check it.

Okay, we fixed this by reverting the commit 70af08e849a93d56915b7abe14537facf1022a6a and are going to do 3.4.1-rc3.

*** Bug 38587 has been marked as a duplicate of this bug. ***

(In reply to comment #11)
> Okay, we fixed this by reverting the commit
> 70af08e849a93d56915b7abe14537facf1022a6a and are going to do 3.4.1-rc3.

It seems that the bug is still in the master.

Best regards. JBF

(In reply to comment #13)
> (In reply to comment #11)
> > Okay, we fixed this by reverting the commit
> > 70af08e849a93d56915b7abe14537facf1022a6a and are going to do 3.4.1-rc3.
> 
> It seems that the bug is still in the master.
> 
> Best regards. JBF

Ok, explications given by moggi on irc. Thanks.

(In reply to comment #0)
> Created an attachment (id=48323) [details]
> spreadsheet with charts which cause probable memory leak
> 
> Steps to reproduce:
> - open the attached spreadsheet with LibO 3.4.1 rc1
> - go to the bottom of the sheet to show the charts
> - navigate in the sheet several times in order to show and hide the charts
> - after a moment it becomes impossible to save the file : too many files open !
> 
> In fact, if you look at the temporary folder used by LibO, you can see that
> Calc create many new temp files each time a chart becomes visible.
> With the attached file I reach quickly ~1000 files
> result of ulimit -n command : 1024 ...
> 
> Best regards. JBF

JBF,

Can you tell me

1) how many times (roughly) do I need to show and hide the charts in order to reproduce this?

2) where do you look to see the temp files that LibO creates, preferably on Linux?  Is it /tmp?

3) What are the names of those temp files?  Is there a pattern in the naming?

I'm trying to fix Bug 36688, and I'd like to make sure that I won't re-introduce this bug while fixing it.

Thanks,

Kohei

Well, I did notice that I got tons of /tmp/lu41n115.tmp/lu41n*.tmp as I scrolled through the test document.  Each scroll-through would increase the number of temp files there.  With my (hopefully proper) fix for Bug 36688, I only see one temp file, and the number doesn't increase even after repeated scrolling, so I assume I've fixed Bug 36688 the right way.