Issue 112766 - Massive 64bit Memory Leak when run on Linux Server
Summary: Massive 64bit Memory Leak when run on Linux Server
Status: CONFIRMED
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: OOo 3.2.1
Hardware: All Linux, all
: P2 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-28 17:55 UTC by drichard
Modified: 2013-02-07 22:43 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Very visible memory leak. (336.38 KB, image/png)
2010-06-28 17:56 UTC, drichard
no flags Details
The best valgrind I could get before the Java blocker dialog (19.79 KB, text/plain)
2010-06-28 17:56 UTC, drichard
no flags Details
Top from today, you can see the users that remain in the start center (123.80 KB, image/png)
2010-07-02 17:44 UTC, drichard
no flags Details
Extensions that are currently installed, most are from Sun. (108.43 KB, image/png)
2010-07-07 16:56 UTC, drichard
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description drichard 2010-06-28 17:55:27 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.
Comment 1 drichard 2010-06-28 17:56:07 UTC
Created attachment 70272 [details]
Very visible memory leak.
Comment 2 drichard 2010-06-28 17:56:38 UTC
Created attachment 70273 [details]
The best valgrind I could get before the Java blocker dialog
Comment 3 michael.ruess 2010-07-01 09:17:42 UTC
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?
Comment 4 drichard 2010-07-01 19:16:54 UTC
@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.
Comment 5 michael.ruess 2010-07-02 15:49:41 UTC
MRU->MBA: this is not reproducible in "normal" Workstation environment. Does the
valgrind .log give any useful information?
Comment 6 drichard 2010-07-02 17:44:57 UTC
Created attachment 70373 [details]
Top from today, you can see the users that remain in the start center
Comment 7 caolanm 2010-07-07 15:25:34 UTC
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."
Comment 8 caolanm 2010-07-07 16:30:44 UTC
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.
Comment 9 Mathias_Bauer 2010-07-07 16:37:02 UTC
I would like to know if there is anything else installed that interacts with
OOo. Extensions, macros, additional components etc.
Comment 10 drichard 2010-07-07 16:56:44 UTC
Created attachment 70445 [details]
Extensions that are currently installed, most are from Sun.
Comment 11 drichard 2010-07-07 17:11:02 UTC
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.
Comment 12 Mathias_Bauer 2010-07-07 17:25:51 UTC
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?
Comment 13 drichard 2010-07-07 21:47:35 UTC
@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.