Red Hat Bugzilla – Bug 119354
Possible severe memory leak in X11
Last modified: 2007-11-30 17:10:39 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):
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
X server still holding several hundred megs of memory
The X server frees the memory allocated in conjunction with running
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
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.
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,
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:  AGP version 2.0
Capabilities:  Power Management version 2
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:  Power Management version 2
Capabilities:  AGP version 3.0
Created attachment 99064 [details]
lsmod of wombat, the FC1 machine
Created attachment 99065 [details]
lsmod of gibraltar, the FC2 machine
Created attachment 99067 [details]
XF86Config of wombat
Created attachment 99068 [details]
XF86Config of gibraltar
Created attachment 99069 [details]
/var/log/XFree86.0.log of wombat
Created attachment 99070 [details]
/var/log/XFree86.0.log of gibraltar
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.
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
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.
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.
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
For me, gimp on fedora core 2 is useless.
Instead I use RH7.2 and gimp 1.2.5 which has no problem.
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"