Bug 90524 - Memory leak in headless mode
Summary: Memory leak in headless mode
Status: RESOLVED DUPLICATE of bug 41288
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: sdk (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-09 09:43 UTC by Gabriel Niebler
Modified: 2015-04-16 11:03 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gabriel Niebler 2015-04-09 09:43:23 UTC
Memory leak in headless mode

LibreOffice leaks memory when it's started in headless mode and used via the Python-UNO bridge.

Steps to reproduce:

I'm assuming you're running the following commands in bash (although the shell shouldn't matter) on some flavour of Linux.
You'll need several shell sessions; in the steps outlined below I put bracketed numbers on front of the prompt to
distinguish them.

1. Prepare the template file

Open LO, create a new, empty document, save it to '/tmp/empty.odt'.

2. Start LO in headless mode with this command:

(1)$ libreoffice --headless --nologo --norestore --accept="socket,host=localhost,port=2048;urp;StarOffice.ServiceManager"

3. Start monitoring memory usage

Find the PIDs of LO and its child processes with 'pstree -p' then run 'ps -Fp ...' to see the memory size (SZ) and real set size (RSS).

(2)$ ps -Fp 22517,22541,22543,22545,22546,23276,23278,22529,22540
UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
user 22517 20597  0  6845  2196   0 09:40 pts/1    00:00:00 /usr/lib/libreoffice/program/oosplash --headless --nologo --norestore --accept=socket,host=localhost,port=2048;urp;StarOffic
user 22541 22517  0 42195 17288   0 09:40 pts/1    00:00:00 /usr/lib/libreoffice/program/soffice.bin --headless --nologo --norestore --accept=socket,host=localhost,port=2048;urp;StarOf

4. Use the Python-UNO bridge to open and close the empty template repeatedly

(3)$ python
...
>>> import sys
>>> sys.path.append('/usr/lib/libreoffice/program')

You may have to adjust this path to wherever LO on your system installs its 'uno.py' and 'unohelper.py' files.

>>> import uno
>>> import unohelper
>>> localContext = uno.getComponentContext()
>>> resolver = localContext.ServiceManager.createInstanceWithContext("com.sun.star.bridge.UnoUrlResolver", localContext)
>>> context = resolver.resolve("uno:socket,host=127.0.0.1,port=2048;urp;StarOffice.ComponentContext")
>>> desktop = context.ServiceManager.createInstanceWithContext("com.sun.star.frame.Desktop", context)
>>> def open_and_close(times):
...     for i in range(times):
...             document = desktop.loadComponentFromURL('file:///tmp/empty.odt', "_blank", 0, ())
...             document.close(0)
...             del document
...
>>> open_and_close(1000)
(wait for this function to return)

All this does is that it opens and closes the empty template document '/tmp/empty.odt' 1000 times.

5. Check memory consumption of the LO process

(2)$ ps -Fp 22517,22541,22543,22545,22546,23276,23278,22529,22540
UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
ganieb00 22517 20597  0  6845  2196   0 09:40 pts/1    00:00:00 /usr/lib/libreoffice/program/oosplash --headless --nologo --norestore --accept=socket,host=localhost,port=2048;urp;StarOffic
ganieb00 22541 22517  3 57206 89140   0 09:40 pts/1    00:02:13 /usr/lib/libreoffice/program/soffice.bin --headless --nologo --norestore --accept=socket,host=localhost,port=2048;urp;StarOf

Note how memory use shot up and stays at this level, even though the actual work finished.
Comment 1 Gabriel Niebler 2015-04-09 09:47:51 UTC
This issue was present in OpenOffice.org before the fork, here's the bug on AOO's bug tracker:
https://bz.apache.org/ooo/show_bug.cgi?id=105191

It has been reported against LibreOffice before, as Bug 41288:
https://bugs.documentfoundation.org/show_bug.cgi?id=41288
That bug #41288 was closed as INVALID, though, due to the submitter losing interest and not supplying any more info.
Comment 2 Buovjaga 2015-04-16 11:03:42 UTC
Thanks! I'll close this as duplicate then. You can comment on the older report, if you wish, I just set it to NEW.

*** This bug has been marked as a duplicate of bug 41288 ***