https://bugs.freedesktop.org/show_bug.cgi?id=66419
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #5 from [email protected] --- 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? -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
