[olpc-software] XRes Improvements

[Daniel P. Berrange]

On Tue, Mar 14, 2006 at 10:12:47PM -0800, L. David Baron wrote:
> On Tuesday 2006-03-14 21:53 +0000, Daniel P. Berrange wrote:
> > http://people.redhat.com/berrange/olpc/performance/
> 
> ...in which you wrote:
> 
> # Running these tests revealed some interesting & unexpected results.
> # The first test starting releasing pixmaps on the X server when total
> # memory usage hit about 74 MB, with 12 pages loaded into history. The
> # remaining tests *never* freed any pixmaps even after 50 pages / 220 MB
> # of pixmaps are loaded. The stack traces associted with the XFreePixmap
> # calls show some form of reference counting garbage collection is
> # taking place to release pixmaps. The graphs would later tests suggest
> # that this reference counting is broken when multiple tabs are open. On
> # the plus side, the client side memory usage appears to be sane, with
> # the only significant increase in usage being demonstrated when opening
> # a new tab for every single web page loaded.
> 
> I tried some non-automated testing in trunk Firefox, and found (in gdb)
> that XFreePixmap was being called when I expected it to be, even when
> loading various images alternately between two tabs.  Loading new images
> evicted old ones from the memory cache, calling XFreePixmap.  (I had to
> weed out *tons* of other XFreePixmap calls related to temporary drawing
> surfaces, and some related to Xft, though.)
> 
> I could try to see if I can replicate these results if I knew what
> versions of both Firefox and Epiphany you were using.  Some versions are
> nontrivial for me to build and install, especially since current
> epiphany doesn't build on FC4 (it's too old!).
> 
> The reference counting shouldn't be too error-prone, although there are
> actually multiple reference counts to care about, since the refcounted
> nsImageGTK objects in Mozilla own a reference to refcounted GdkPixmap
> objects which in turn own the pixmap.  I'd think Mozilla would be likely
> to leak those nsImageGTK objects mainly in the case where it leaked a
> substantial chunk of the data structures for the entire document, but I
> could be wrong.

So I've done a few more tests today. First I switched to using a 32-bit 
OS instead of a 64-bit one - still saw the same growth in pixmap cache.
I then tried loading the 50 pages by hand, instead of via Dogtail - still
saw growth in pixmap cache. So, then I created a completely  new UNIX
user to ensure a clean & predictable configuration - now firefox behaved
normally with the pixmaps being purged once a threshold was reached. So
I went back to my original UNIX user account & deleted $HOME/.mozilla and
deleted by my GTK/GNOME/Mozilla config files & then magically firefox
was behaving normally on this account too. 

A little more poking around and I discovered that the only difference between
my two user accounts was that one had  accessibility support enabled. So I
enabled a11y support on the new user account too & now firefox started leaking
pixmaps again.

So to reproduce this try

 * Select 'Desktop -> Preferences -> Accessibility -> Assistive Techology Support'
   menu item in desktop session
 * In the config tool enable the 'Enable assistive technologies' checkbox
 * Restart GNOME login session
 * Launch firefox and open two tabs & load pages

On my system, when enabling assitive technologies, Firefox will load two extra
components:

  /usr/lib/firefox-1.0.7/components/libaccessibility.so
  /usr/lib/firefox-1.0.7/components/libcomposer.so 

So it looks like this particular memory issue is somewhere in the accessibility 
stack - possibily the GTK layer of it, rather than firefox.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|