Issue 105191 - Memory leak in headless mode.
Summary: Memory leak in headless mode.
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOO310m9
Hardware: PC Linux, all
: P3 Trivial with 21 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
: 102790 (view as issue list)
Depends on:
Reported: 2009-09-18 21:41 UTC by smonsarr
Modified: 2017-05-20 10:45 UTC (History)
9 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Test Case to Demonstrate Memory Leak (1.16 KB, patch)
2009-09-24 11:15 UTC, akvadrako
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description smonsarr 2009-09-18 21:41:40 UTC
Computer config: 
Ubuntu 8.10 server, 2Gb RAM, no X11.

OpenOffice started in headless mode and used as a server accessed from a java
app (using either a socket or a pipe connection).
In our context the java app asks OpenOffice to open a given odt file and perform
an update (the equivalent to menu Tools>Update>Update All).

OpenOffice leaks substatial amounts of memory each time an ODT file is processed.
Processing the same small 3 page odt (83Kb) including 3 images leaked around
25MB per test.
After 100 iterations the resident memory of the soffice process was around
1400MB and OpenOffice finally crashed. 
Processing a 187 page odt (9.8Mb) including 229 images leaked around 75MB per test.

When OpenOffice is started without the -headless option but with a xvfb server
as a X11 substitute, the soffice process does not leak any memory using the same
odt files. The soffice process generally evens out at around 190MB of resident

Using xvfb on a headless OpenOffice server would seem like a acceptable
work-around but OpenOffice crashes while updating large ODTs. Running the exact
same test using a "real" X server or with the -headless option is successful.
Comment 1 akvadrako 2009-09-24 11:15:12 UTC
Created attachment 64928 [details]
Test Case to Demonstrate Memory Leak
Comment 2 akvadrako 2009-09-24 11:17:47 UTC
I can confirm this problem in RHEL5 with OOo 3.1.1

Running with the attached test case (open/close/repeat) leaks memory with this
command line:

   soffice $OOO_OPTS $OOO_ACCEPT -headless

but not with this one:

   soffice $OOO_OPTS $OOO_ACCEPT -invisible

OOO_OPTS="-display :99 -nologo -norestore -nofirststartwizard"
Comment 3 Olaf Felka 2009-10-14 07:13:59 UTC
@ sb: Something for you?
Comment 4 Stephan Bergmann 2009-10-14 08:04:24 UTC
@hdu:  Since the leak happens with -headless but not with -invisible it is
unlikely the UNO remote communication that causes the problem, more likely
related to VCL?
Comment 5 2009-10-14 09:03:13 UTC
Indeed, this looks like an issue in basebmp or vcl/unx/headless. Reassigning accordingly.
Comment 6 philipp.lohmann 2009-10-19 14:33:34 UTC
Comment 7 philipp.lohmann 2009-11-06 13:41:36 UTC
There are currently several obstacles fixing this: the python script cannot run,
it ends up with assertions out of cppuhelper "this and that type not found".
valgrinding with as described in the wiki crashes rather
soon and without valgrind does not find very much wenn doing e.g. a "./soffice
-headless -p empty.odt"

pl->sb: could you please clear those obstacles in cppu and sal, so valgrind
works and the testcase runs ?
Comment 8 Stephan Bergmann 2009-11-09 10:12:05 UTC

"assertions out of cppuhelper":  Cannot reproduce that problem (DEV300m63; make sure to run the with the python executable from a
recent OOo installation (not necessarily the shebang one at /opt/openoffice...).

"valgrinding with":  issue 105898
Comment 9 philipp.lohmann 2009-11-09 10:17:08 UTC
Ah that probably explains the crashing. I'll wait for fwk120 to be integrated
then, thanks.
Comment 10 lszyba1 2009-11-23 15:34:15 UTC
Any news on this?
I've recently switched from oo2.4 due to URP bridge disconnects. 
The connection lost was fixed in the 3.1.1, but now the memory issue in headless
is impossible to deal with. Doing 30-60 page processing is no longer possible in
headless. Non-headless mode works just fine do.

Is any additional information needed? 
Estimated version for the fix?

Thanks a lot,
Comment 11 philipp.lohmann 2009-11-23 15:54:59 UTC
Sorry, nothing new. I'm still waiting for issue 105898 to be fixed, which makes
valgrinding impossible.
Comment 12 lszyba1 2009-12-24 20:04:24 UTC
Issue 105898 seems to be fixed?

It says:
"fixed in CWS fwk120 (revisions 276972, 276973).

thanks to cmc for the suggestion!"

Let me know.
Comment 13 philipp.lohmann 2010-01-27 18:39:00 UTC
@hdu: valgrind results are not quite conclusive, however one place where memory
seems to get lost in svp is SvpGlyphPeer::GetGlyphBmp (svptext.cxx:106)

could you please have a look ?
Comment 14 philipp.lohmann 2010-02-02 10:11:28 UTC
Comment 15 lszyba1 2010-02-25 15:05:07 UTC
Is the fix ready for release? I was under impression that issue was found and
solved? Is it?
Comment 16 2010-02-25 15:16:14 UTC
No, the status is "not quite conclusive... please have a look"
Comment 17 lszyba1 2010-03-17 20:28:22 UTC
@hdu, where you able to look at this problem? I really need the fix for this. We
have ~200 page documents that generate daily and I always need to watch for
memory or segmentation error issues(daily), until this is resolved!!!

I would appreciate if you could find some time this week to look at this, and
maybe find why the headless module is leaking memory, especially looking at why
the memory is not released after closing a document. I can always live with a
small memory leak, but if 500kb memory per document is not released, then that
would be my primary target for fixing!? 

Comment 18 Stephan Bergmann 2010-06-28 10:55:38 UTC
*** Issue 102790 has been marked as a duplicate of this issue. ***
Comment 19 2010-08-16 14:40:54 UTC
Comment 20 sraps 2010-10-12 07:24:35 UTC
I just wanted to note that this and very similar issues has been reported since
7 (!!!) years. So it is very limiting to use OOo in batch conversion
applications, as now servers grow in their performance and one may need to
restart OOo instance every ten minutes to keep up the performance. It is not for
real life application.

Here are the very similar bug reports, I have gathered:

In my case problem exists when OOo instance is being started in headless mode,
when started with UI and operated from UNO everything seems ok. This is existent
on various Linux distributions with various OOo versions starting from 3.0 and
up. So it is not about setup.
Comment 21 Marcus 2017-05-20 10:45:23 UTC
Reset the assignee to the default "".