Closed Bug 259672 Opened 20 years ago Closed 18 years ago

Lots of X pixmap resources allocated: xfree86 grows very fast

Categories

(Core Graveyard :: GFX: Gtk, defect)

Product:
Core Graveyard
Component:
GFX: Gtk
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: fabiano, Assigned: tor)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040820 Galeon/1.3.17 (Debian package 1.3.17-1)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040820 Galeon/1.3.17 (Debian package 1.3.17-1)

Mozilla, Firefox and Galeon don't free X resources for pixmaps,
if you open an image or browse a url with images and then change
to another page none of the allocated pixmaps are freed.

I did this experiment:
- set mozilla to start in a blank page and then restart it;
- look the allocated X resources with xrestop. I had this for my
  browser:
   1 - Mozilla ( PID:  ?   ):
        res_base      : ox1600000
        res_mask      : ox1fffff
        windows       : 73
        GCs           : 37
        fonts         : 1
        pixmaps       : 57
        pictures      : 5
        glyphsets     : 2
        colormaps     : 0
        passive grabs : 0
        cursors       : 26
        unknowns      : 6
        pixmap bytes  : 465804
        other bytes   : ~4600
        total bytes   : ~470404
- now open some url with images, about:logo for example. In my
  case:
   1 - logo.gif (GIF Image, 200x200 pixels) - Mozilla ( PID:  ?   ):
        res_base      : ox1600000
        res_mask      : ox1fffff
        windows       : 87
        GCs           : 37
        fonts         : 1
        pixmaps       : 65
        pictures      : 5
        glyphsets     : 2
        colormaps     : 0
        passive grabs : 0
        cursors       : 26
        unknowns      : 6
        pixmap bytes  : 633464
        other bytes   : ~4936
        total bytes   : ~638400
- then go to another page without images, chrome://global/content/MPL-1.1.html
  (another internal page to isolate the problem), and I had this:
   1 - Mozilla Public License version 1.1 - Mozilla ( PID:  ?   ):
        res_base      : ox1600000
        res_mask      : ox1fffff
        windows       : 87
        GCs           : 37
        fonts         : 1
        pixmaps       : 68
        pictures      : 5
        glyphsets     : 4
        colormaps     : 0
        passive grabs : 0
        cursors       : 26
        unknowns      : 6
        pixmap bytes  : 635576
        other bytes   : ~4984
        total bytes   : ~640560
You can see that the pixmap bytes allocated in the Xserver for the
logo image aren't freed (almost 160Kb).

Just to check, restart and open only the license page. My xrestop -b show
this:
1 - Mozilla Public License version 1.1 - Mozilla ( PID:  ?   ):
        res_base      : ox1600000
        res_mask      : ox1fffff
        windows       : 73
        GCs           : 37
        fonts         : 1
        pixmaps       : 57
        pictures      : 6
        glyphsets     : 4
        colormaps     : 0
        passive grabs : 0
        cursors       : 26
        unknowns      : 6
        pixmap bytes  : 465804
        other bytes   : ~4672
        total bytes   : ~470476
As expected no new pixmaps.

I can repoduce this in debian sid with:
  mozilla 1.7.2
  firefoz 0.9.3
  galeon 1.3.17
using XFree86 4.3.0

The same thing happens if you open an image file from
the filesystem.


Reproducible: Always
Steps to Reproduce:
1. open url about:logo and look the xrestop -b output
2. open url chrome://global/content/MPL-1.1.html 
3. look the xrestop -b output again, pixmap are not freed in xserver

Actual Results:  
Pixmap resources are not freed in xserver as expected.

Expected Results:  
Free all pixmap resources allocated in xserver
Is this a problem with mozilla.org builds, or just Debian ones?
Unless you're seeing uncontrolled growth of the pixmap resources, this
is just mozilla's normal image cache behavior.

(In reply to comment #1)
> Is this a problem with mozilla.org builds, or just Debian ones?

Debian ones, but I will try mozilla.org builds today.
(In reply to comment #2)
> Unless you're seeing uncontrolled growth of the pixmap resources, this
> is just mozilla's normal image cache behavior.

Why mozilla do this cache inside of xserver pixmap memory? 

I have 800Mb of memory (real+swap) and just openning image
files from local disk with mozilla my xserver consumes all
this memory.

(In reply to comment #3)
> (In reply to comment #1)
> > Is this a problem with mozilla.org builds, or just Debian ones?
> 
> Debian ones, but I will try mozilla.org builds today.

I tried with firefox from mozilla.org (firefox-1.0PR-i686-linux-gtk2+xft)
and had the same behavior.

(In reply to comment #4)
> (In reply to comment #2)
> > Unless you're seeing uncontrolled growth of the pixmap resources, this
> > is just mozilla's normal image cache behavior.
> 
> Why mozilla do this cache inside of xserver pixmap memory? 
> 
> I have 800Mb of memory (real+swap) and just openning image
> files from local disk with mozilla my xserver consumes all
> this memory.
> 

There is some way to limit or turn off this cache?
(In reply to comment #6)
> (In reply to comment #4)
> > (In reply to comment #2)
> > > Unless you're seeing uncontrolled growth of the pixmap resources, this
> > > is just mozilla's normal image cache behavior.
> > 
> > Why mozilla do this cache inside of xserver pixmap memory? 
> > 
> > I have 800Mb of memory (real+swap) and just openning image
> > files from local disk with mozilla my xserver consumes all
> > this memory.
> > 
> 
> There is some way to limit or turn off this cache?

I don't know if this:
  user_pref("browser.cache.disk.enable", false);
  user_pref("browser.cache.memory.enable", false);
in prefs.js turn off the cache completely, but even so
the browser doesn't release the pixmaps allocated in
xserver.
Maybe it is related with bug 213391.
> Why mozilla do this cache inside of xserver pixmap memory? 

Because otherwise we end up with the image data in both the pixmap memory and
the Mozilla address space for displayed images.

> my xserver consumes all this memory.

That sounds like a bug indeed.  The image cache should be bounded by some
fraction of the total available RAM...
Depends on: 213391
Total available RAM on the machine Gecko is running on may be completely
unrelated to the amount of RAM available on the machine the X server is running
on, of course.
Yeah, well.  We suck with remote X in all sorts of ways; I've given it up as a
lost cause.  :(
See also bug #257016 -- is this a dupe of that?
1. Start up Firefox
           rbase     nwin  ngc  nfon npix misc    pixmem    oth   total
<TreMobyl> 4a00000    87   37    1   31   17      416K      4K    420K   ?  
Mozilla Firefo

2. Load graphics-heavy page
<TreMobyl> 4a00000   132   38    1   93   43   107433K      5K 107439K   ?  
Halloween Phot

3. Open new empty window
<TreMobyl> 4a00000   185   38    1   95   45   107443K      7K 107450K   ?  
Halloween Photos, 2002 - Mozilla Firefox

4. Load text-only page in new window
<TreMobyl> 4a00000   185   38    1   99   49   107452K      7K 107460K   ?  
Halloween Photos, 2002 - Mozilla Firefox

5. Close first window
<TreMobyl> 4a00000   111   38    1   82   45    49833K      5K  49839K   ?  
Punalot - Mozilla Firefox


This is Firefox 1.0.


Federico, 50MB worth of graphics sounds like just memory cache...  To check, see
about:cache (and try clearing cache to see whether that makes the memory use go
down?).
The default memory cache size is calculated here:

  http://lxr.mozilla.org/seamonkey/source/netwerk/cache/src/nsCacheService.cpp#1242

We allow the cache to exceed this size to handle all active objects (like
all the images on a graphics intensive page).

#251380 related? dupe?
I don't understand why this bug is said to depend on #213391.  That one, like
several other local commenters, misunderstand the particular cache being abused
here.  It is not the mozilla-side memory or disk cache, but the X server-side
pixmap cache that appears to grow without bound.
Frank, that dependency and the comments here are based on the fact that mozilla
keeps its image cache server-side in pixmaps.
*** Bug 257016 has been marked as a duplicate of this bug. ***
I just created a toy program to illustrate the effects of keeping compressed images in the client, and decompressing them on demand when painting the window.   It would work quite well for the case with a local X server.

Please see this: http://primates.ximian.com/~federico/news-2005-11.html#moz-images
Federico, on what kind of machine did you run those tests?
An ideal solution for machines with relatively modern GPUs would be to support compressed images in the Xserver, decompressed with GPU assistance. Some older graphics chips without full programmability have hardwired JPEG decoding.
(In reply to comment #21)
> Federico, on what kind of machine did you run those tests?

My laptop; 1.5 GHz Pentium M, 512 MB RAM (it's a Thinkpad T41p).

I haven't measured how this performs over remote X - it can't be worse than any regular "keep the images in the client" app :)

Indeed, if one could ship JPEG or PNG images to the X server, it would be ideal.  Let's poke KeithP about it; he mentioned wanting to do something like that at one point.
Shipping compressed images to the X server sounds good but the speed problem may hit us again. Decompressing on every draw is simply not fast enough over a range of pages and machines. However, once we have the compressed data on the X server, it can choose an appropriate strategy:
-- decompress immediately (we still saved bandwidth to the X server, good for remote connections)
-- decompress on every draw (if we have a fast machine, fast SSE2 code, or hardware JPG decoding)
-- partially decompress immediately and decompress the rest on every draw (e.g. for JPEG, decompress immediately to YUV with subsampled chroma --- only half the size of 24-bit RGB; subsampled YUV->RGB is relatively easy to do with the GPU).

The latter was suggested by a graphics guru friend.
I don't think we need to get very exotic; we just need some good code to decompress JPEGs.

Compare the loading speed of a large JPEG between libjpeg and Photoshop.  PS is absurdly, ridiculously, fantastically fast.  We should be able to do that.

You can still pull some tricks even if you don't have as fast a decoder as Photoshop's.  You could just do the first decompression stage but keep the DCT blocks around, and uncompress those on demand.  You can evict them based on a timer, or a LRU scheme, or whatever.
See bug 247437 for some discussion of the SSE2 JPEG decoding code. I haven't tried it myself but maybe we should benchmark it again.

I still vote for shipping JPG blocks to the X server and then you and Keith can do whatever you want there :-).
Depends on: 247437
(In reply to comment #26)
> I still vote for shipping JPG blocks to the X server and then you and Keith
> can do whatever you want there :-).

While I think you're half joking about this...

A better strategy would be a two fold one.  Firstly, implement a MIME type extenstion for the X server, which allows it to support image/gif, image/jpeg, image/png, etc (with some mechanism to specify the level of support).  That way it is extensible, and one day when the X server starts to understand audio/wav, audio/mp3, video/mpeg, etc, these can just be integrated into Firefox, Gnome, KDE, etc.

Secondly, move the image decoding and encoding to a cairo helper library.  There are already enough libraries out there, including for Gnome, EFL, etc.  This way the image library and cairo can agree on the best surface type, and Gecko doesn't have to worry about images (well as much).  This has the advantage that libpr0n can pass a cario surface around (or some Thebes object), and rendering of SVG into <image> is made simpler.  This way, only cairo has to be taught about the MIME extension on the X server, and it can decide when to use it...

Plus, the optimisations are also kept where they belong - in the various libraries like libjpeg, in the X server, or in cairo.  And we might get the benefit of GTK/Gnome using them, so they will be better tested and debugged.

*** Bug 318681 has been marked as a duplicate of this bug. ***
Please keep in mind that in thin client situation the thin client that is running the X server could only have 64 Mb of RAM and no swap, while the terminal server where the firefox is running could have dual opterons with a few gigs of RAM. Just throwing all JPEGs to the X server even in compressed form could be deadly to the thin client.
I think the best short time solution would be to keep all data in compressed form in Firefox and decompression should only be done for currently displayed images (directly to the displayed window, so no extra memory used) and maybe a fixed amount of pre-rendering.
And when X server would start to understand storing JPEG, PNG, GIF compressed images the only change could be just to send the pre-rendering data in compressed form thus increasing the amount of pre-rendering.
The X server would have the option of decompressing JPGs as soon as they arrive, which is really no worse than what currently happens.
-> tor
Assignee: blizzard → tor
I can confirm pixmaps still leak in Firefox 1.5.

Firefox is using 252MB in firefox-bin and 412MB in 4699 pixmaps in X, with one tab open (this bug), after about 3 days uptime.

The number of memory cache entries is a mere 652. There are more than 4000 pixmaps which don't correspond to potentially active images.

Some of this discussion (post #20 on) seems to have focused on Gecko using too much memory for the pixmaps it has stored, but in fact this bug was originally about Gecko storing too many pixmaps!

Will a potential fix for this bug translate to a fix for Windows as well (if Firefox stores uncompressed pixmaps in X, does it also store uncompressed images under Windows)? The memory hog behavior might be cross-platform. Obviously this is not a GTK or X issue under Windows, but Firefox has an unusually high memory footprint after loading a pages with images. Furthermore, the memory footprint does not decrease appreciably when closing image-heavy pages. Any comments?
I think the discussion about what to do with jpg in xfree is nice but pointless for this bug as storing the jpg compressed or not, the amount of memory consumed is growing constantly. So the question for me is "Why the cache is not purged" - if that's really a cache, as I do not see this problem with Mozilla Suite, but Firefox draws machine unusable after few days of usage.
This bug also seems to exist under Windows, at least my Firefox does end up hogging hundreds of megabytes after a while, even with all-but-one tabs closed and browser.cache.memory.capacity set to 32768.
Whatever you see on Windows, it's not this bug.  This bug is about a specific issue that is only relevant on Unix.
Boris: however, even though the mechanisms are different (X versus Win32), it seems that in BOTH cases the uncompressed image files (whatever format) remain somewhere in the memory and limiting the cache size doesn’t quite change a damn thing about it :)

I’ve read the bug and bug comments, and it looks suspiciously similar on both X and Win32, so this is why I suspect there has got to be something unspecific to the windowing system that results in the overly huge resource usage.

It seems that Eugene (#34) also chimed in with a similar comment -- do you happen to know of a bug dealing with that?  It might be a good idea to have a link to it if there is one (might result in less Win32-related comments here, too :D).
I'm not aware of a Windows bug on the issue.  Someone who can reproduce the problem and thus provide specific numbers should file one.
Most certainly Windows problem isn't related to this bug, but to these instead:
https://bugzilla.mozilla.org/show_bug.cgi?id=213391
https://bugzilla.mozilla.org/show_bug.cgi?id=194296
*** Bug 323995 has been marked as a duplicate of this bug. ***
I've been through the sources in LXR looking at references to

gdk_pixmap_new
gdk_pixmap_create
gdk_pixmap_colormap_create
XCreatePixmap

but I haven't seen any leaks evident. In all cases pixmaps are released with calls to

gdk_pixmap_unref (happily, no matches for gdk_pixmap_ref to confuse matters)
XFreePixmap

either within the function or in an appropriate destructor. I couldn't see any reason why these would fail to be called if the wrapper classes/structures were cleaned up properly.

I suspect therefore that Mozilla is actually leaking these classes. This would suggest a common cause for similar behaviour on Windows. It might also explain why the firefox-bin process seems to also grow without bound.
Got a sequence of test steps that actually shows such unbounded growth?  People here seem to be complaining that images are cached aggressively, not that they're never released (the latter would be a leak, the former is not).  Given bfcache, please remember that 5 pages worth of images that you're NOT looking at are being cached too.
To clarify:  Firefox is *not* leaking pixmaps on X nor bitmap resources on Windows.  It just allocates too many of them.  This is fine when you have plenty of RAM available (i.e. it gets put to a good use), but it's bad when those allocations cause paging to happen.

My proposal in comment #20 is to keep images compressed in Firefox, and uncompress them on demand.  The example program shows that this does not have a bad effect on perceived performance (and it can be improved a lot, anyway).

I'm sorry that I don't have the time right now to implement the necessary changes myself.
(In reply to comment #43)
> Got a sequence of test steps that actually shows such unbounded growth?  People
> here seem to be complaining that images are cached aggressively, not that
> they're never released (the latter would be a leak, the former is not).  Given
> bfcache, please remember that 5 pages worth of images that you're NOT looking
> at are being cached too.

It's easy to test "unbounded growth"; just load many tabs with many images and keep them open.

There are a few things we can do:

1. Keep images compressed in memory, and uncompress them on demand when they are about to be exposed.  Discard the uncompressed data as soon as the image stops being visible in the screen (i.e. the user switches to a different tab, or scrolls away).  My example program is just about this behavior.

2. If we have the machinery to uncompress images on demand, we can also mmap() the cached image files themselves instead of malloc()ing space for them.  Then the kernel doesn't even have to page out the compressed data, since it's already on disk; it just has to page it back in if some other process pushed us out of RAM.

If we uncompress images on demand *AND* mmap the compressed images from the on-disk cache, we don't even need to put an upper limit on memory consumption for images, since the problem just goes away :)
Summary: X pixmap resources leak: xfree86 grows very fast → Lots of X pixmap resources allocated: xfree86 grows very fast
I disagree with comment #44. Firefox _is_ leaking pixmaps. It's easy to test.

1. Open xrestop.
2. Open about:cache.
3. Browse graphics-heavy pages with Firefox until the memory cache is full.
4. Continue to surf.

From about:cache, cache entries and memory usage stay bounded.
In xrestop, Pixmap allocation and Pixmap memory usage are unbounded.
I’ll chime in again for a little if I may.  Can’t give you really technical and detailed stuff, but here goes anyway.

When I start Firefox up, it’s around 40RAM+40VM.  The cache settings are 32 mebi in memory and 50 mega on disk.  I browse around and Firefox will slowly fatten up to about 100 to 110 megs in RAM plus 80 to 100 megs on disk.  For some reason the caches say they’re using only up to their limits, which sounds seriously fishy to me, because they do say the same when Ff is barely using 60+60 of memory according to the Windows task manager.

Federico’s earlier findings (I happened across his log from November; wanted to contact you about this, Federico, but I weren’t able to yet, so I’m glad you’re here sharing your thoughts on the issue) suggested that at least on versions of the browser running on X11, retain pixmaps in memory, uncompressed at that, and don’t seem to clean up after themselves anywhere before closing the application.  I can confirm something similar is happening on Windows, and cache bounds don’t seem to affect it.

The cached objects are indeed uncompressed.  Yesterday I saw that a 1177 bytes big png file had been occupying 315000 bytes in my cache, simply because it was stored as a bitmap.  Federico’s suggestions would take care of this on both (all?) platforms; and I don’t see why it couldn’t become an about:config option for people who require the old way of things.

It can be argued that cache is a cache and that’s why it isn’t purged even after closing the tabs etc., but I guess size limits for the cache should be enforced more strictly than the expiration time.  On that, during yesterday’s browsing I did, in fact, see Firefox free up memory, from the 110M+100M high it would slowly wander back down to 90M+90M or thereabouts.

Sorry that this was so long; but the discussion seems to be going on here and it seems (without actually seeing the source) that both issues are caused by a common bug.  Cache bounds just aren’t respected on either platform.
Compressing might help a bit, but in the long run it's not a solution.

I'm working on an application generating a lot of pictures. After usually one hour of testing, firefox was reaching the 600-800 MB range which made the computer unusable. So enforcing the memory cache limit is needed.
Please don't add me to the cc field of this bug again while people insist on repeating the same things that were already said ad nauseam...
what about a configurable option to Enable/Disable purging the pixmaps after some limit.
This way everyone will get the behaviour we have now.
And if u enable purging after some limit based for example on LRU u know that your FF will not grow over specified limit.
So until we figure out will we compress/decompress, where exactly to do this..ppl will have a way to control over constant FF grow.
This option will be usable even if the problem is solved in some way.

People, please either observe bugs in the "depends on" list (or at post #40. My bad :-$ )
This bug is (or at least "was") not about excessive usage of X resources, or lack of preference to be more "agressive" about freeing X resources, it's indeed almost a _leak_ of X resources since the resources are nerver, ever, released.
This very probably not even specific to X, but a direct consequence of https://bugzilla.mozilla.org/show_bug.cgi?id=213391.
What comment #45 describes could be helpful for bug 120809 too if you look at the discussion there.
After browsing 4chan.org 's hr for a while, and closing the relevant tabs so that bfcache shouldn't be able to skew the results, I still have over 1GB of pixmap cache used on the X server, which is insane (I only have 512MB RAM, 1GB swap).
Quoting xrestop:

xrestop - Display: localhost:0
          Monitoring 31 clients. XErrors: 20
          Pixmaps: 1315323K total, Other:     130K total, All: 1315453K total

res-base Wins  GCs Fnts Pxms Misc   Pxm mem  Other   Total   PID Identifier
3200000   371  103    1  284   78   1295061K     13K 1295075K   ?   Bug 259672 -1600000    28   72    1    8   80     5906K      5K   5911K  5937 Terminal

There clearly is a leak here.

It also appears that some requests to the X server got interrupted, because before closing the tabs, some images which had been completely loaded from the network (there is a 'image corrupted' message when downloading of image is interrupted by a closed connection) were dispayed only partially, only the first  few lines being rendered on screen; zooming/dezooming doesn't alter this, so it seems the pixmaps that the x server owns are partially blank. The X error count mentionned by xrestop could be related to this.


So after browsing for several days, leaving the browser always up i got this when i arrived home:

 3239 root      15   0 2158m 1.7g 3740 S 19.6 85.6 334:41.64 X                                                                       
10788 higuita   15   0  279m 100m 9768 R  1.7  5.0  50:33.49 firefox-bin 

i have 2Gb of ram and last time i use it (2 days ago) the system was working fine... today the HD was allways swapping, even if i was doing nothing...
seems that the heavy usage and maybe some banner rotating in this last days have eatten all my memory.

after i close firefox the X was like this:
 3239 root      15   0  475m  44m 3200 S  2.2  2.2 334:49.87 X

so how does firefox takes 300Mb of ram and then makes the X to have 1.7Gb just for it!!?

as i killed firefox, i could recover the sites and this is the same pages loaded after restarting it:

 3239 root      15   0  475m 125m 3744 R  1.7  6.2 337:05.12 X                                                                       
22340 higuita   15   0  233m 110m  18m R  0.0  5.5   1:19.37 firefox-bin

the exact same pages took about 80Mb of X11, very far from the previous 1700Mb...

i can see very easily that this in a low memory x terminal its a HUGE problem, see bug 296818, if i have 2Gb and it almost killed my system, in a 64Mb xterminal its probably almost impossible to use (but as related with this one, i would recommend this bug to block 296818)

i'm using firefox 2.0 with just the default dom inspector and talkback installed...

Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

so now that firefox memory usage seems to have decreased, X11 memory is still too high

thanks
It seems OK (tried 3.0a6pre), after closing most tabs of a heavy session, the xrestop usage goes down fromm 150 to 40Mb first, then after browsing a few text pages, 17Mb. I set browser.sessionhistory.max_total_viewers to 0 before trying. It seems firefox still considers the X server OK for caching recently closed tabs and pages (I disagree), but it doesn't seem to be leaking these resources anymore.
Ok, thanks for testing, please file a new bug should it occur again.

-> WORKSFORME
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
See bug #296818 for a work-in-progress patch for the general problem of keeping images as uncompressed pixmaps in the X server.
This bug should be marked as depends on bug #395260. When it's patch gets committed, this bug can change status from "RESOLVED WORKSFORME" to "FIXED".
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.