Apache OpenOffice (AOO) Bugzilla – Issue 112766
Massive 64bit Memory Leak when run on Linux Server
Last modified: 2013-02-07 22:43:28 UTC
erAck mentioned on the IRC to create this report and mark it P2. We deployed 3.2.1 on a 64bit Linux server for the first time and it's leaking horribly in Writer. Each time that users open new documents it's grabbing around 100M of memory which is never released even after the document is closed and they return to the Start Center. Those that are opening and closing documents all day are using 1, 2 or 3G of memory. It's very easily to replicate. I log in as a user, and then just close and re-open documents the memory consumption goes up. We never saw this issue on the 32bit version. I'm attaching a screenshot of top showing how the users are using up far more memory than they should. I tried to use valgrind, but was never able to get it past the first document opened. It continues to loop and report that Java was not found which is blocking me from continued leaking. I disabled Java and tried that and it's in a loop requesting that I enable Java. So the attached valgrind shows the first document being opened, at which time I had to control-c out because of the java dialog loop. Issues worth mentioning: - Software is being run to remote display to thin clients. - THin clients are set to 16bit color depth. The work around was to purchase and install enough memory to hold our highest concurrent loads, but this obviously is not a good long term solution.
Created attachment 70272 [details] Very visible memory leak.
Created attachment 70273 [details] The best valgrind I could get before the Java blocker dialog
Does it only happen with Writer documents or also with Calc/Draw/Impress/Math/Base? Did you deploy native build from OOo or the one from the Linux distributor?
@mru: Ok, I spent about 30 minutes today testing. Yes we are running vanilla OOo downloaded right from the Sun/Oracle site. We are not using OOo shipped with the distro. It appears that both Calc and Writer are both never releasing memory when you return to the Start Center, however Calc is not impacting us much because it's not growing at the same rate. With very small documents, Calc is growing about 1MB each time the document is opened and the memory is never released when the document is exited and we return to the start center. Writer is growing about 50MB-100MB on each document, and memory is never released when the document is closed and they return to the start center. Obviously, closing OOo completely releases the memory. It seems like there are twofold problems: 1) Writer is consuming what to me is way too much memory when a document is opened. 2) The memory in both Calc and Writer should be returned once the document is closed. Fixing #2 would help us more, because we have users that work in OOo all day and consume huge amounts of memory by the end of the day. I can valrind for you if I can get some up to date instructions how how it works and how to get past the Java dialog that I'm getting. Let me know what command line flags to use and I can upload them for you; it's very easily replicated.
MRU->MBA: this is not reproducible in "normal" Workstation environment. Does the valgrind .log give any useful information?
Created attachment 70373 [details] Top from today, you can see the users that remain in the start center
Using my own x86_64 3.2.1 build, which is effectively the same as vanilla, i.e. no magic leak patches added, just to test the most basic case, i.e... Launch soffice.bin -writer get its PID and top -p thatpid PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 17993 caolan 20 0 930m 82m 61m S 0.0 1.4 0:01.01 soffice.bin close writer window, back to start panel 17993 caolan 20 0 951m 88m 63m S 0.0 1.5 0:01.40 soffice.bin file->new->document 17993 caolan 20 0 951m 88m 63m S 14.6 1.5 0:01.85 soffice.bin close writer window, back to start panel 17993 caolan 20 0 952m 89m 63m S 1.7 1.5 0:02.17 soffice.bin file->new->document 17993 caolan 20 0 951m 88m 63m S 1.3 1.5 0:02.66 soffice.bin close writer window, back to start panel 17993 caolan 20 0 952m 89m 63m S 8.3 1.5 0:02.93 soffice.bin file->new->document 17993 caolan 20 0 951m 88m 63m S 14.3 1.5 0:03.43 soffice.bin so it looks like we're stable in memory use in that scenario. cmc->drichard: do you get basically the same with this test. i.e. iterating through "Launch a single blank writer window", close it back to the start panel, and reopening another single blank writer window."
As an aside issue 112783 and issue 112898 and issue 102142 are three "accumulator" leaks that I'm aware of right now, but I doubt that any of them would be responsible for massive leakage. Definitely not 102142 anyway, as that would be on the XServer side only.
I would like to know if there is anything else installed that interacts with OOo. Extensions, macros, additional components etc.
Created attachment 70445 [details] Extensions that are currently installed, most are from Sun.
Ok, after some testing on a clean m84 install it's not leaking in the same manner. I have uploaded the extensions we have loaded, so it seems like the theory that they are not unloading after a document is opened is valid. It seems like the only one that touches documents immediately that are opened is LanguageTool.
LanguageTool could be a good guess, especially as none of the other is heavily involved into text documents (I don't know the non-Sun extensions, but I guess that they are not of that kind). So deinstalling LanguageTool and testing again would be nice. As I assume that the extension is installed for all users, it would require a restart of the complete OOo process to make sure that it is removed completely. Would that be possible, e.g. over night when hopefully no users are working with OOo?
@all: Ok, it's extensions for sure. For my test I used m84. Stock m84 with no extensions: I closed and reopened documents from the start center over and over again and it didn't really show any major growth in memory. m84 + Language Tool extension: Just opening and closing a simple document it started to leak and on each open and close consumed more memory. However, it should be noted that the memory jumps appear not to be as significant as the live version which has about 10 total extensions. So that leads me to believe that very possibly they all are contributing to this issue. Language tool has been in use here for many years on 32bit Linux and we never saw this problem. A leak in the plugin itself to me would be returned once the document is closed and you return to the start center. So it seems still that this is a problem with OOo.