Problem description: Memory leaks in LibreOffice when I just open, get document text and close document several times using python-uno. But I think it is not problem of Python UNO but LibreOffice itself. All test was done on Ubuntu 11.04 + LibreOffice 3.4.3 + python-uno + python 2.7.1. I put the python code below just in case. Also I found that for GSOC 2011 one of ideas was "Search for, and fix memory and resource leaks" (http://wiki.documentfoundation.org/Development/Gsoc/Ideas#Search_for.2C_and_fix_memory_and_resource_leaks). It is why I think the problem is in libreoffice. Steps to reproduce: 1. Start libreoffice in terminal without gui using following command: libreoffice --accept=socket,host=localhost,port=2002;urp;StarOffice.ServiceManager --norestore --nofirststartwizard --nologo --headless 2. In second terminal I starts python code to open some file, get text and close it several time 3. Using 'top' command I see that memory that libreoffice use is growing and growing. Expected behavior: Without memory leaks. Minimum python code to reproduce problem (may be it helps): import uno local = uno.getComponentContext() resolver = local.ServiceManager.createInstanceWithContext( "com.sun.star.bridge.UnoUrlResolver", local) context = resolver.resolve( 'uno:socket,host=localhost,port=2002;urp;StarOffice.ComponentContext') desktop = context.ServiceManager.createInstanceWithContext( "com.sun.star.frame.Desktop", context) for i in range(1000): doc = desktop.loadComponentFromURL('some_url', "_blank", 0, ()) plain_text = doc.Text.getString() doc.dispose() doc.close(False) del doc
I get this: ImportError: No module named uno
Please, install python-uno on Ubuntu: sudo aptitude install python-uno If you don't have LibreOffice you can also install it: sudo aptitude install openoffice.org openoffice.org-writer
(In reply to comment #0) > doc = desktop.loadComponentFromURL('some_url', "_blank", 0, ()) __main__.IllegalArgumentException: URL seems to be an unsupported one.
Instead of "some_url" you can use any url to file with document. For example, I have: http://dl.dropbox.com/u/318944/python-uno/hello.doc
I know very little about uno. On pc Debian x86-64, with master branch updated today, I tried to reproduce the pb and had this : warn:legacy.osl:23080:1:/home/julien/compile-libreoffice/libo/desktop/source/app/appinit.cxx:276: Acceptor could not be created. bash: urp : commande introuvable bash: StarOffice.ServiceManager : commande introuvable ("commande introuvable" is French and means "unfound/unknown command") Could you give a try to a newer version of LO 3.5.3 ?
(In reply to comment #5) > I know very little about uno. On pc Debian x86-64, with master branch updated > today, I tried to reproduce the pb and had this : > warn:legacy.osl:23080:1:/home/julien/compile-libreoffice/libo/desktop/source/app/appinit.cxx:276: > Acceptor could not be created. > bash: urp : commande introuvable > bash: StarOffice.ServiceManager : commande introuvable > > ("commande introuvable" is French and means "unfound/unknown command") > > Could you give a try to a newer version of LO 3.5.3 ? Really, doesn't matter UNO or you can just open and close any a doc-file several hundreds times. Memory leaks inside LibreOffice itself. But anyway you can close this bug because we can't use LibreOffice for our project by several reasons. Most of all LibreOffice doesn't understand MS Word format correctly. Often styles of documents are broken after document was open and save. Sorry, It's another story.
First thank you for your quick feedback. About Word document, LO has improved a lot since 3.4.3, you should try last version 3.5.3.2. In addition with new functions, there have been lots of fixes, perf optimization and memory leaks fixes, cleaning, etc. Don't hesitate to open a new tracker with a Word file (or several) which don't work.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of FDO
Setting to NEW as this was confirmed in a new report, bug 90524.
*** Bug 90524 has been marked as a duplicate of this bug. ***
This is a very old bug that has been around for years and years and was reported many times in OpenOffice long before the advent of LO. I reported https://bz.apache.org/ooo/show_bug.cgi?id=105191 back in 2009 but the bug goes back farther then that.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170103
Dear Anatoly, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear Anatoly, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Created attachment 191046 [details] An example document generating a larger memory leak than the document supplied with the official example.
Tested in November 2023: Ubuntu 20 with LO v6.4.7.2 and 7.5.8.2. > Still there via a C++ call. An easy way to generate the problem is to use the example provided with the SDK: https://api.libreoffice.org/examples/cpp/DocumentLoader/ 1 - on T1 : libreoffice "--accept=socket,host=localhost,port=2083;urp;StarOffice.ServiceManager" 2 - Run ubuntu "system monitor" with a "soffice" filter 3 - Note the memory value ~ 50Mb 4 - On T2 run the sample with the sample provided or the document I have attached. 5 - Note the memory value 6 - Repeat steps 4-5-... After 1000 tasks, the process memory usage is ~ 1.2 Gb Add: xComponent->dispose (); after loadComponentFromURL helps a little, but not that much. If you put a loop around loadComponentFromURL, you have the same problem, the problem seems to be located in the code behind loadComponentFromURL. Removing the loadComponentFromURL line removes the leak... Even when waiting, memory consumption doesn't decrease... This bug is a real problem, because having to close the process and reopen it takes an enormous amount of time that is not compatible with microservice architecture, and the size of the leak is a problem for the sizing and the execution environment. If I can help by doing some tests, I'm finishing compiling libreoffice-core today... however, I don't do Python... Regards
Example of a community tool affected by these bugs: https://github.com/unoconv/unoserver/issues/74 https://github.com/unoconv/unoserver/issues/83
The same problem occurs when you use the user interface to open several documents: writer, drawer... until you close the last instance, the memory keeps increasing...
This problem seems to be Linux specific, as I could not reproduce the problem with LibreOffice 7.6 on Windows: Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 20; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded The memory usage is stable around 330 MB, and does not change much after 1000 tasks created with the provided Python code and the sample attached document.
On Linux, I get an exception when using debug build: warn:sal.osl:76556:76562:sal/osl/unx/socket.cxx:1573: receive socket [0] failed: EOL Traceback (most recent call last): File "memory.py", line 12, in <module> doc = desktop.loadComponentFromURL('file:///.../document.odt', "_blank", 0, ()) __main__.DisposedException: Binary URP bridge disposed during call at /home/user/core/binaryurp/source/bridge.cxx:615 Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 45217ca5ba0d4e78b462a10072a4334342cc402c CPU threads: 12; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: CL threaded On the other hand, I could reproduce the problem on Linux release. After 1000 tasks, the memory consumption went above 1.5 GB. Version: 7.6.1.2 (X86_64) / LibreOffice Community Build ID: f5defcebd022c5bc36bbb79be232cb6926d8f674 CPU threads: 12; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Same issue using bootstrap (automatic pipe) Reference<XComponentContext> const xContext { bootstrap ()}; Reference<XMultiComponentFactory> const xFactory { xContext->getServiceManager ()}; ...