Bug 66419 - UI: macro call to close() or dispose() fail to terminate soffice processes
Summary: UI: macro call to close() or dispose() fail to terminate soffice processes
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
Whiteboard: BSA
Depends on:
Reported: 2013-06-30 21:10 UTC by Vieri
Modified: 2016-03-25 06:35 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Vieri 2013-06-30 21:10:26 UTC
When I close an odt document/application with a java macro such

XModel xDocModel = xScriptContext.getDocument();


XCloseable xcloseable = (XCloseable) UnoRuntime.queryInterface(
    XCloseable.class, xDocModel);
try {
} catch (Exception e) {

OR with a Basic macro containing the call to:


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: release
Comment 1 Cor Nouws 2013-07-01 07:21:51 UTC
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.
Comment 2 Vieri 2013-07-16 12:30:46 UTC
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.

Comment 3 the_letter_j 2013-10-06 16:48:41 UTC
This bug might be a (programmatic) cousin of the same (gui) behavior shown in bug#59686 , which was confirmed in LibreOffice rc and also 4.0.5 


@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.
Comment 4 Vieri 2013-10-07 07:02:07 UTC
(In reply to comment #3)

Please note: using LO v.

0.   disable libreoffice quickstarter (verify no soffice*.* in taskmgr) 
1.   start > scalc
2.   tools > macros > organize macros > libreoffice basic 
3+.  (insert appropriate steps here) 

Sub MyAppClose

' close app

End sub
Run 'MyAppClose'.
LO GUI closes (user doesn't see GUI anymore) but these processes are still running in the background:

N-1. look in taskmgr.exe to verify soffice is still running 

are still running

N.   try to open another .odt (how exactly?) and it will never visually appear 

I'm using v. 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. doc1.odt opens correctly and seems to "reuse" the soffice* processes running in the background.
I currently can't test v. as I had to downgrade (at this stage v. 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).
Comment 5 the_letter_j 2013-10-07 17:29:02 UTC
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:  

And here is somebody in 2011 with the exact same problem: 

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:   

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?
Comment 6 the_letter_j 2013-10-07 17:38:16 UTC
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).
Comment 7 the_letter_j 2013-10-07 17:43:38 UTC
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?
Comment 8 Vieri 2014-04-10 06:13:38 UTC
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.
Comment 9 QA Administrators 2015-06-08 14:42:55 UTC
** 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)

   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)


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
Comment 10 Frederic Mestayer 2016-03-10 16:47:25 UTC
Windows 7 :
Bug still there with LibreOffice
No quickstarter loaded/installed.

Launch LO Writer.
Add an macro (Tools->Macros->Manage Macros->Lo Basic)

Sub Main
End Sub

Execute macro.

Writer UI closes...
...but there are 3 processes left in memory (!) :
Comment 11 MNS 2016-03-25 06:35:03 UTC
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()
	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.