When I close an odt document/application with a java macro such as: XModel xDocModel = xScriptContext.getDocument(); xDocModel.dispose(); OR: XCloseable xcloseable = (XCloseable) UnoRuntime.queryInterface( XCloseable.class, xDocModel); try { xcloseable.close(true); } catch (Exception e) { e.printStackTrace(); } OR with a Basic macro containing the call to: thisComponent.close(true) then the soffice.{bin,exe} processes keep running in the background when they shouldn't (even on Windows, I'm not using the quickstarter). I'm expecting the processes to terminate after .close() (I don't want the extra memory footprint). I don't know if this is specific to Windows 7 but I believe it should be considered a bug unless 'thisComponent.close(true)' is NOT equivalent to exiting the LO app from the UI (if I do so from the UI then there are NO soffice.{bin,exe} processes runnign in the background). A side-effect is that if I try to open another .odt file AFTER I run 'thisComponent.close(true)' then it won't show up on screen (I will end up having several soffice.bin/.exe processes running but no GUI). This seems to happen with LO 4. However, I also tested OpenOffice 3.x on Windows XP and in that case, the second .odt file DOES open and seems to re-use the same soffice.bin/.exe processes. This is still not "right" because I'm expecting to be able to terminate the whole OOo processes from a macro call but at least from a user point of view, subsequent odt opening/closing work fine. So I guess LO and/or Windows 7/XP have a different behavior compared to OOo. Operating System: Windows 7 Version: 4.0.4.2 release
Hi Vieri, Isn't thiscomponent simply the active document (frame sometimes)? I doubt that what you try is the way to close the full LibreOffice process. Regards, Cor
Could you please tell me what's the correct way to close a LO process from Basic or Java? I haven't found any documentation suggesting anything else. Thanks
This bug might be a (programmatic) cousin of the same (gui) behavior shown in bug#59686 , which was confirmed in LibreOffice 4.0.0.1 rc and also 4.0.5 https://bugs.freedesktop.org/show_bug.cgi?id=59686 @Vieri, did you ever make any progress with closing programmatically? Can you post a concise set of steps to reproduce this problem, like this: 0. disable libreoffice quickstarter (verify no soffice*.* in taskmgr) 1. start > scalc 2. tools > macros > organize macros > libreoffice basic 3+. (insert appropriate steps here) N-1. look in taskmgr.exe to verify soffice is still running N. try to open another .odt (how exactly?) and it will never visually appear Methinks your bugreport is still unconfirmed, because there is no easy to confirm whether or not thisComponent.close(true) functions properly until we figure out (and reproduce) what exact steps you are trying to take.
(In reply to comment #3) Please note: using LO v. 4.0.3.3 0. disable libreoffice quickstarter (verify no soffice*.* in taskmgr) DONE 1. start > scalc DONE 2. tools > macros > organize macros > libreoffice basic DONE 3+. (insert appropriate steps here) created: Sub MyAppClose ' close app ThisComponent.Close(True) End sub Run 'MyAppClose'. LO GUI closes (user doesn't see GUI anymore) but these processes are still running in the background: soffice.exe soffice.bin N-1. look in taskmgr.exe to verify soffice is still running soffice.exe soffice.bin are still running N. try to open another .odt (how exactly?) and it will never visually appear I'm using v. 4.0.3.3 and I usually launch the following command to open a document: "C:\Program Files\LibreOffice 4.0\program\soffice.exe" -o https://myserver/webdav/docs/doc1.odt With v. 4.0.3.3 doc1.odt opens correctly and seems to "reuse" the soffice* processes running in the background. I currently can't test v. 4.0.4.2 as I had to downgrade (at this stage v. 4.0.4.2 would NOT open the odt) but as soon as I can I'll test the latest LO release (currently 4.1.2). In any case, I found that the macro call 'ThisComponent.Close(True)' never terminates the soffice* processes even in OpenOffice (so it's not just a LibreOffice issue).
Confirmed buggy on Ubuntu 12.04.3 with LibreOffice 3.5.7 Observed behavior: when following the steps outlined by Vieri, I was able to reproduce the ram-hog part of his bug report, but not the part where he experienced a pid-hog (i.e. the refusal to re-launch LiO). [He says the latter only impacts very specific recent versions of LiO.] Here is when the macro had exited, but LiO still hung around in the bkgd, using up 135mb of physical ram: $ ps aux | grep office | grep -v grep j 13386 0.0 0.0 209448 3456 ? Sl 10:31 0:00 /usr/lib/libreoffice/program/oosplash --writer j 13405 0.6 1.1 5700600 135856 ? Sl 10:31 0:04 /usr/lib/libreoffice/program/soffice.bin --writer --splash-pipe=6 I was able to launch LiO again successfully, by clicking the icon on the OS quicklaunch bar, after which it re-used the same processes from above: $ ps aux | grep office | grep -v grep j 13386 0.0 0.0 209448 3456 ? Sl 10:31 0:00 /usr/lib/libreoffice/program/oosplash --writer j 13405 0.5 1.1 5700600 135856 ? Sl 10:31 0:04 /usr/lib/libreoffice/program/soffice.bin --writer --splash-pipe=6 When I then (manually with the mouse as opposed to programmatically with the macro snippet) closed LiO writer, the processes were gone. $ ps aux | grep office | grep -v grep (no output) Expected behavior: after a macro call ThisComponent.Close(True), there should no longer be any ram used by LiO, since the quickstarter is off. Notes: this was a one-line macro in a custom-named Sub, which did not use any Declare Lib statements (and thus needed no FreeLibrary calls). Based on a post from 2004, also tried to use ThisComponent.dispose which has the same behavior (exits but does not free up the RAM). Here is somebody with the same general problem back in 2009: http://forum.openoffice.org/en/forum/viewtopic.php?f=20&t=19088 And here is somebody in 2011 with the exact same problem: http://www.vbforums.com/showthread.php?640100-close-quot-openoffice-Impress-quot-macro&s=c87c9a8139d9e59e082119f993fcd72d&p=3954976&viewfull=1#post3954976 Under the product whose name we shall not spake, Application.Quit is the appropriate incantation. Various forums claims that the equivalent in LibreOffice is supposed to be ThisComponent.Close(True) , or in the olden days, failing that to try ThisComponent.Dispose Also possibly(?) relevant is the OnCloseApp event of LibreOffice. Workaround published in 2010: http://forum.openoffice.org/en/forum/viewtopic.php?f=20&t=37023#p170071 When I used the one-liner StarDesktop.terminate , in place of the usual ThisComponent.Close(True) , at first it seemed to act just the same as the others... the visible gui-portion disappeared, but the processes remained in RAM. However, after about ten seconds, I got a system-level crash (the equivalent of DrWatson in the Windows world) that told me /usr/lib/libreoffice/program/soffice.bin "has experienced an internal error" and thanked me for coming and hoped I had a wonderful time BYE. There are always alternatives, and in this case, I recommend that you try to use taskkill on windows or killall-nee-kill on unix-like systems. That is not very clean, but it seems to be the only way (at present) to get LibreOffice to give up that RAM it is clinging to for dear life. Can you try out Stardesktop.terminate on your system -- making sure to save everything first, and make backups, in case it hoses you somehow?
p.s. Is there a reason *why* LiO does not implement Application.Quit , which is what the average VBA programmer would expect to find available? I recall in the bad old days when formulas had to contain semicolons instead of commas, just so that Sun/Oracle could claim to be different than Microsoft. But aren't we past that now? Suggest adding the alias for Application.Quit to LibreBasic, while the traditional ThisComponent.Close functionality is fixed to stop being a ram-hog (i.e. actually exit and free all ram unless quickstarter is active).
To test this, you need to have quickstarter turned off: tools > options > libreoffice > memory > quickstarer unchecked You also need to have the JRE installed and associated with LiO: tools > options > libreoffice > java > use java checked I was testing with OpenJDK 1.6.0_27 ... maybe Java7 works better? @Vieri, what JVM vendor and version are you using for your tests?
Sorry for the late reply but I didn't get an e-mail notification. Tried with Java versions 1.7.0_51 and 1.6.0_20.
** 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 (4.4.3 or later) 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 your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-06-08
Windows 7 : Bug still there with LibreOffice 5.1.1.3 No quickstarter loaded/installed. Launch LO Writer. Add an macro (Tools->Macros->Manage Macros->Lo Basic) Sub Main ThisComponent.close(true) End Sub Execute macro. Writer UI closes... ...but there are 3 processes left in memory (!) : soffice.exe soffice.bin swriter.exe
One way to terminate the soffice process and any of its child process on Windows Platform is to make use of ExitProcess() API. Declare Sub ExitProcess lib "Kernel32.dll" (nExitCode as Integer) Private Sub QuitApp() ThisComponent.Close(True) ExitProcess 0 End Sub When soffice instance is created for the next time (such as when a document is opened) a recovery window will popup. It can be ignored because no change is found to be made to the document, after recovery. Otherwise, once can make use of -norestore flag of soffice.exe to suppress recovery window.