Issue 85321 - OOo caches large pixmaps to X server, crashing the X server.
Summary: OOo caches large pixmaps to X server, crashing the X server.
Status: CLOSED FIXED
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 2.3
Hardware: All Unix, all
: P2 Trivial with 2 votes (vote)
Target Milestone: OOo 2.4
Assignee: hdu@apache.org
QA Contact: issues@gsl
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-17 09:27 UTC by www_gmc
Modified: 2009-01-09 18:11 UTC (History)
4 users (show)

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


Attachments
patch to fix pixmap leak (529 bytes, patch)
2008-01-21 10:39 UTC, caolanm
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description www_gmc 2008-01-17 09:27:53 UTC
Hi,

this issue particularly affects thin clients (eg LTSP) and is not limited to
OpenOffice (see also firefox bug
https://bugzilla.mozilla.org/show_bug.cgi?id=395260).

The LTSP communities (also edubuntu) have had reports of both Impress and Writer
crashing thin clients where a large amount of image data is placed in the
document.  The application pushes the pixmap image data across onto the X server
which is forced to allocate memory to store it.

http://sourceforge.net/mailarchive/forum.php?thread_name=478EC01A.1040904%40logicalnetworking.net&forum_name=ltsp-discuss

Thin clients are often low power, low memory units who only provide the display,
they don't actually run applications.  They may have 128MB RAM or sometimes even
less.  By contrast the server running the application usually has a lot of RAM
and CPU power.  Unfortunately this pixmap caching shifts the memory footprint
from the application server to the thin client causing it to crash (single
pixmap images can be 10s of megabytes).

It may be feasible for X to discard these images¹ but this is a hack and may
well destabilise the application.  It seems a better solution for the
application to be more cautious about what pixmaps it caches and when it purges
them from the cache.

Gavin

¹ https://lists.ubuntu.com/archives/edubuntu-users/2007-December/003060.html
Comment 2 lns 2008-01-17 18:04:53 UTC
I am having the same issues as Gavin (I am currently in charge of 4 LTSP student
labs of ~35 systems each and growing). It is plainly reproducible in an LTSP
environment, especially with thin-clients of 128MB or less.

Server output:
---
$ sudo dpkg -l  |grep "OpenOffice"
ii  openoffice.org                        1:2.3.0-1ubuntu5.3

$ uname -a
Linux xxxxx 2.6.22-14-server #1 SMP Tue Dec 18 08:31:40 UTC 2007 i686 GNU/Linux

$ cat /etc/debian_version 
lenny/sid
---

Steps to reproduce (from an LTSP thin-client):

1) Open OOo Word Processor
2) Open Tools -> Gallery
3) Launch a terminal and start 'xrestop' (install if you don't have it). Note
where OOo is.
4) Start dragging/dropping and moving around as many clipart images as possible.
 Watch xrestop as OOo starts consuming all of the memory on the thin-client,
eventually locking the entire X11 session (as it consumes *all* of the memory).


This is a showstopper for the whole district, as OpenOffice is a key component
to our curriculum. Unfortunately, with this LTSP related bug, the teachers are
starting to scoff at the stability of the entire system. Any help at all would
be greatly appreciated, as I know there are *many* other LTSP admins having the
same issue. I'm just one of them speaking up right now. =) I'd be glad to help
testing any proposed fixes, as long as it doesn't involve any coding work (IANAP).

My full issue reported on LTSP-DISCUSS mailing list, including more hardware
information:
http://www.mail-archive.com/ltsp-discuss@lists.sourceforge.net/msg33337.html

Thanks!!

Sincerely,
Jordan Erickson
Comment 3 caolanm 2008-01-18 17:39:10 UTC
.
Comment 4 caolanm 2008-01-18 20:02:22 UTC
I can easily reproduce an interesting sub-part of this. simply opening the
gallery and then clicking on backgrounds and then clicking on bullets increases
pxms by 2, clicking on backgrounds, then +2, click on bullets +2 etc. 

I'll have a look on Monday and identify where that apparent leak is coming from
at least.
Comment 5 caolanm 2008-01-21 10:38:21 UTC
So heres my before and after on running writer and opening the gallery...

Before:

res-base Wins  GCs Fnts Pxms Misc   Pxm mem  Other   Total   PID Identifier
3400000    45   82    1  267   57     4285K      5K   4290K 20719 Untitled1 -
OpenOffice.org Writer

res-base Wins  GCs Fnts Pxms Misc   Pxm mem  Other   Total   PID Identifier
3400000    45   82    1   97   59     4242K      5K   4248K 20386 Untitled1 -
OpenOffice.org Writer

So I've knocked 170 pixmaps out of it to get to that stage. Patch for that leak
attached. I'm not sure that this *solves* this problem and that this can be
closed, but its definitely a major part of the problem I suspect.
Comment 6 caolanm 2008-01-21 10:39:17 UTC
Created attachment 51047 [details]
patch to fix pixmap leak
Comment 7 philipp.lohmann 2008-01-21 11:26:30 UTC
confirm leak

fix is safe, so I think we can get that into 2.4 yet
Comment 8 philipp.lohmann 2008-01-21 12:29:22 UTC
committed in CWS fwk83
Comment 9 philipp.lohmann 2008-01-21 12:29:58 UTC
please verify in CWS fwk83
Comment 10 hdu@apache.org 2008-01-21 12:45:10 UTC
Verified.
Comment 11 hdu@apache.org 2008-04-02 10:54:27 UTC
Got integrated into milestone OOH300_m6 and SRC680_m246 => closing.
Comment 12 www_gmc 2008-04-02 11:18:26 UTC
Thanks for this.

We haven't actually verified that this bug fixes our X server crash issue, but I
guess we can reopen it.

Will this fix be in OOo 2.4.1 and OOo 3?

Gavin
Comment 13 www_gmc 2008-04-02 11:40:38 UTC
Thanks for this.

We haven't actually verified that this bug fixes our X server crash issue, but I
guess we can reopen it.

Will this fix be in OOo 2.4.1 and OOo 3?

Gavin
Comment 14 hdu@apache.org 2008-04-02 12:34:30 UTC
> We haven't actually verified that this bug fixes our X server crash issue, but I guess we can reopen it.

Yes, certainly.

> Will this fix be in OOo 2.4.1 and OOo 3?

Yes, it is already in OOo 2.4.0 and will be in newer versions too, of course.
Comment 15 lns 2009-01-09 01:31:40 UTC
I am seeing much improvement from this fix, as I work with 7 schools currently
that use OOo in a thin client environment. However, the OOo Presentation app
Slide Show function seems to cache excessive amounts of pixmap data still (in
2.4.1). Please see
https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/315300 for my
description on this. It seems maybe this function was missed with the leak fix,
though IANAP so I can't verify the code. Please don't hesitate to e-mail me with
questions, as this fix will be highly anticipated by my schools' staff and students.

Thanks,
Jordan Erickson
Comment 16 hdu@apache.org 2009-01-09 07:51:25 UTC
> the OOo Presentation app Slide Show function seems to cache excessive amounts of pixmap data still

@thb: I suspect one of the Canvas implementations is running wild.

@www_gmc: Please open a new issue for the remaining problem in presentation mode.
Comment 17 thb 2009-01-09 11:31:55 UTC
@www_gmc: does disabling hardware acceleration in the Tools->Options->View
tabpage change the behaviour? Other than that, I concur with hdu, please file me
a new issue for the slideshow problem.
Comment 18 lns 2009-01-09 18:04:46 UTC
Hardware acceleration in the Tools->Options->View tabpage is disabled by default
- I enabled it just to see what would happen on my thin client - running Slide
Show from the same presentation gave ~24MB pixmap memory used (from same 5MB
baseline when presentation is simply opened), but things are extremely choppy
when HW Accel is enabled. 

I will open a new issue. Thanks for such a quick response!!
Comment 19 lns 2009-01-09 18:11:21 UTC
New issue filed here: http://qa.openoffice.org/issues/show_bug.cgi?id=97906