Apache OpenOffice (AOO) Bugzilla – Issue 105191
Memory leak in headless mode.
Last modified: 2017-05-20 10:45:23 UTC
Computer config: Ubuntu 8.10 server, 2Gb RAM, no X11. Setup: 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). Issue: 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 memory. 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.
Created attachment 64928 [details] Test Case to Demonstrate Memory Leak
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_SOCK_ARGS="socket,host=127.0.0.1,port=8100,tcpNoDelay=1" OOO_ACCEPT=-accept="$OOO_SOCK_ARGS;urp;StarOffice.Service" OOO_OPTS="-display :99 -nologo -norestore -nofirststartwizard"
@ sb: Something for you?
@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?
Indeed, this looks like an issue in basebmp or vcl/unx/headless. Reassigning accordingly.
target
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 libsalalloc_malloc.so 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 ?
@pl: "assertions out of cppuhelper": Cannot reproduce that problem (DEV300m63 unxlngi6.pro); make sure to run the memleak.py with the python executable from a recent OOo installation (not necessarily the shebang one at /opt/openoffice...). "valgrinding with libsalalloc_malloc.so": issue 105898
Ah that probably explains the crashing. I'll wait for fwk120 to be integrated then, thanks.
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, Lucas
Sorry, nothing new. I'm still waiting for issue 105898 to be fixed, which makes valgrinding impossible.
Issue 105898 seems to be fixed? It says: "fixed in CWS fwk120 (revisions 276972, 276973). thanks to cmc for the suggestion!" Let me know. Thanks, Lucas
@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 ?
reassign
Is the fix ready for release? I was under impression that issue was found and solved? Is it?
No, the status is "not quite conclusive... please have a look"
@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!? Thanks, Lucas
*** Issue 102790 has been marked as a duplicate of this issue. ***
.
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: http://qa.openoffice.org/issues/show_bug.cgi?id=105191 http://www.openoffice.org/issues/show_bug.cgi?id=41675 http://qa.openoffice.org/issues/show_bug.cgi?id=14349 http://qa.openoffice.org/issues/show_bug.cgi?id=28996 http://qa.openoffice.org/issues/show_bug.cgi?id=98421 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.
Reset the assignee to the default "issues@openoffice.apache.org".