Bug 119354 - Possible severe memory leak in X11
Possible severe memory leak in X11
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: X/OpenGL Maintenance List
Depends On:
  Show dependency treegraph
Reported: 2004-03-29 15:26 EST by Nils Philippsen
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-03 13:32:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
lsmod of wombat, the FC1 machine (2.96 KB, text/plain)
2004-04-02 03:05 EST, Nils Philippsen
no flags Details
lsmod of gibraltar, the FC2 machine (1.99 KB, text/plain)
2004-04-02 03:06 EST, Nils Philippsen
no flags Details
XF86Config of wombat (5.95 KB, text/plain)
2004-04-02 03:35 EST, Nils Philippsen
no flags Details
XF86Config of gibraltar (4.57 KB, text/plain)
2004-04-02 03:35 EST, Nils Philippsen
no flags Details
/var/log/XFree86.0.log of wombat (40.25 KB, text/plain)
2004-04-02 03:36 EST, Nils Philippsen
no flags Details
/var/log/XFree86.0.log of gibraltar (34.55 KB, text/plain)
2004-04-02 03:36 EST, Nils Philippsen
no flags Details

  None (edit)
Description Nils Philippsen 2004-03-29 15:26:26 EST
Description of problem:

When working with gimp-2.0.0 on some rather largish pictures
(~7100x4700 px) I managed to use up all of the physically available
memory, the system literally crawled (tens of seconds between mouse
click or keyboard input until seeing some action). The culprits at
that time were the gimp and the X server, both using memory in excess
of several hundred MB. And now for the bug: when ending the gimp, the
X server still held all the memory allocated instead of freeing it. I
had to restart the X server for the memory to be released.

I could observe this on two machines, one with 512MB of RAM, FC1 but
updated gimp, the other with 1GB RAM and Rawhide of yesterday and soon
to be current gimp packages.

Version-Release number of selected component (if applicable):

FC2 machine:

FC1 machine:

How reproducible:

Easy (you just need large enough images to work with).

Steps to Reproduce:
0. Configure the gimp to actually make use of about 1/2 to 3/4 of your RAM
1. Work with really large images
2. Do many things to fill up the undo buffer, use filters, select and
copy, duplicate images, ...
3. Be fascinated about a real sluggish machine with a real busy harddisk
4. Think "what have I done?", repent for the errors of your ways, try
to frantically save images and close GIMP windows
5. The GIMP is closed, breathe a sigh of relief
Actual results:

X server still holding several hundred megs of memory

Expected results:

The X server frees the memory allocated in conjunction with running
the GIMP.
Comment 1 John Dennis 2004-04-01 17:13:44 EST
When I was tracking down the heap corruption problem earlier this week
I ended up with a static server linked with the dmalloc debugging
library. That's probably a good way to take a look at this so I'll
take ownership of this bug unless you've already done something with
it Mike.
Comment 2 Mike A. Harris 2004-04-02 02:24:15 EST
Thanks John, that would be a help.  I haven't investigated this yet.

Normally, memleak bug reports usually get tracked down to being a bug
in an applications leaking X resources or something, so I don't jump
on them right away as people often come back when they've discovered
the faulty application.

One thing that may help with this issue is "xrestop" which I have
had added to the Fedora devel now.  It can help to spot leaky apps,
etc. and to help determine if it is more likely to be an app leaking
resources, or a true X server bug.  Since this X server is fairly
new however, and hasn't had much public widespread testing, either
case is fairly plausible.

Nils) Can you also please test this with xrestop, and see if you
can see if it is X resource related?  Also, what video hardware
are you using, and can you attach your X server log, config file,
/var/log/messages, output of "lsmod", and any other diagnostic
info you think might help.  screenshots of top/ps/xrestop, etc.

Thanks guys.
Comment 3 Nils Philippsen 2004-04-02 03:02:55 EST
Mike: sure. Do you mean "X server log after the event" or will any log
do? AFAICS, there's nothing unusual so I'll attach the logs as they
are now (unfortunately reproducing the problem as I described it
proved to be not as easy as I wrote above, but if needed I'll attach
the log file of the FC1 machine at home once I can reproduce it (when
I'm at home)).

I'll begin with the hard data:

FC1 plus updated gimp machine:

ATI FireGL 880/128MB:

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R200 QH
[Radeon 8500] (rev 80) (prog-if 00 [VGA])
        Subsystem: ATI Technologies Inc FireGL 8800 128Mb
        Flags: bus master, stepping, 66Mhz, medium devsel, latency 32,
IRQ 12
        Memory at d0000000 (32-bit, prefetchable) [size=256M]
        I/O ports at c000 [size=256]
        Memory at e5000000 (32-bit, non-prefetchable) [size=64K]
        Expansion ROM at <unassigned> [disabled] [size=128K]
        Capabilities: [58] AGP version 2.0
        Capabilities: [50] Power Management version 2

FC2 laptop:

nVidia GeForce 4200/128MB:

01:00.0 VGA compatible controller: nVidia Corporation NV28 [GeForce4
Ti 4200 Go AGP 8x] (rev a1) (prog-if 00 [VGA])
        Subsystem: Dell Computer Corporation: Unknown device 0179
        Flags: bus master, VGA palette snoop, 66Mhz, medium devsel,
latency 32, IRQ 11
        Memory at fc000000 (32-bit, non-prefetchable) [size=80000000]
        Memory at f0000000 (32-bit, prefetchable) [size=64M]
        Expansion ROM at 00020000 [disabled]
        Capabilities: [60] Power Management version 2
        Capabilities: [44] AGP version 3.0

Comment 4 Nils Philippsen 2004-04-02 03:05:46 EST
Created attachment 99064 [details]
lsmod of wombat, the FC1 machine
Comment 5 Nils Philippsen 2004-04-02 03:06:24 EST
Created attachment 99065 [details]
lsmod of gibraltar, the FC2 machine
Comment 6 Nils Philippsen 2004-04-02 03:35:22 EST
Created attachment 99067 [details]
XF86Config of wombat
Comment 7 Nils Philippsen 2004-04-02 03:35:53 EST
Created attachment 99068 [details]
XF86Config of gibraltar
Comment 8 Nils Philippsen 2004-04-02 03:36:20 EST
Created attachment 99069 [details]
/var/log/XFree86.0.log of wombat
Comment 9 Nils Philippsen 2004-04-02 03:36:47 EST
Created attachment 99070 [details]
/var/log/XFree86.0.log of gibraltar
Comment 10 John Dennis 2004-04-13 17:56:11 EDT
O.K., I've looked at this. I built a version of the X server with the
dmalloc library. Then in combination with dmalloc loging and an xres
client watching I used gimp for a while. I didn't see any significant
problems, some minor memory leaks on the order of 20 bytes per leak,
but nothing like what you describe.

Nils, if you still believe there is a problem I'm going to need an
EXACT reproducer, the image file, the exact gimp operations that lead
to memory problem. Otherwise I'm afraid I'm chasing this down a rat hole.
Comment 11 Bernhard Ege 2004-06-15 13:39:09 EDT
I have the same problem although my setup is an up-to-date FC1. Now,
the way I can increase the X-server memory usage is to start gimp
(1.2.5) and load several images. The images I load are gray-scale and
are loaded as indexed images (through a custom loader but that
shouldn't be a problem). When an image is loaded, I convert it to
grayscale using Image->Mode->Grayscale (Alt-G). When I do that, the
x-server consumes more memory. I usually load quite a few of these
images, up to 20, each about 2MB a piece, and do a little processing
on them (usually just thresholding and zooming). After a while, my
x-server get sluggish and I notice the huge memory footprint (approx

I just tested by loading 3 192MB indexed images and converted each to
grayscale when they were loaded. The X-server used 820MB then (my pc
has 512MB, 1GB swap). Needless to say there was severe swapping and it
took quite a while. I asked gimp to quit without saving the images and
then the X-server locked up for 20 minutes while constant harddisk
usage was occuring. The X-server memory usage did not drop after gimp
had quit.

I do have to say that I am using a geforce4 and nvidia's driver, not
the nv driver. I will redo the test when I have switched driver.
Comment 14 Mike A. Harris 2004-09-15 17:54:22 EDT
This issue is believed to be caused due to the large size of
the image allocating memory in the X server, which does get freed,
but is not released until all allocations on same pages get freed
also, which may be quite some time after the large pixmap is freed.

If this is the case, it isn't a memory leak, however it results in
memory not being released for some time once it is freed.  In order
for that problem to be resolved in the X server however isn't a
simple or small bug fix, but a complete rewrite of the memory
management system in the X server.  That type of change is not
something that can be done in a bug fix update.

Please file a bug report at http://bugs.freedesktop.org about this
issue, and put full details into the upstream report.  We will
track the issue in X.Org bugzilla.

Comment 15 Spam Less 2004-11-04 07:28:51 EST
It may not be a bug, but Gimp is useless on Fedora Core 2 for me.
I use gimp/gap. Making small changes (adding but quite a few moving
items on a 200 frame, 600x400 image) very quickly uses up my memory
(256Meg, 512Meg swap) and that is it. I could make one change, save
the files, close gimp, close X, restart X, restart gimp, load the
files, make one change, save the files, close gimp, close X, restart
X, restart gimp, etc., but that is useless.

(Fedora core 2: kernel 2.6.7 from source, xorg-x11-6.8.1-12 from the
fedora core2 development section, gimp 2.0.6, gimp-gap 2.0.2
from source)

For me, gimp on fedora core 2 is useless.

Instead I use RH7.2 and gimp 1.2.5 which has no problem.
Comment 16 Mike A. Harris 2004-12-03 13:32:58 EST
Please upgrade to Fedora Core 3, which ships with xorg-x11-6.8.1,
and then apply all updates we've released.  If the problem still
persists (which if my assumptions in comment #14 above are
correct, it probably will), please be sure to report it directly
in the X.Org bugzilla as previously requested.  X.Org bugzilla
is located at:


Once your bug is reported to X.org, if you would like us to track
the issue in the upstream tracker, and review any fixes that
become available for consideration in future updates, please paste
your X.Org bug report URL here, and we will track the issue there.

Thanks in advance.

Setting status to "CURRENTRELEASE"

Note You need to log in before you can comment on or make changes to this bug.