Description of problem:
With heavy use of Gimp, X consumes virtual memory. When lots of VM has been
used, and Gimp is then exited normally, the disk thrashes for a long, long time.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Use a system monitor such as gkrellm and/or top to watch system memory usage
and swap activity.
2. Run Gimp. Mine is configured with 30 levels of undo and a 32 Mb tile cache
size. Use the paint brush and draw a lot for a couple hours. Use lots of layers
and enable/disable them.
3. Observe X's VM size increase.
4. Observe swap activity increasing.
5. When X's VM usage exceeds approximately half the available VM, exit Gimp
Heavy disk activity begins. It will continue for a long time, perhaps 15 to 30
minutes. If you are lucky, your display will not freeze and you can observe
Gimp's VM usage climb. Many times, soon after the disk thrashing begins, my
display froze and I simply had to wait until the disk activity stopped.
Once, when my display did not freeze, I watched as Gimp's memory usage
climbed rapidly until all VM was consumed. At that point, my display froze, and
I became disgusted and rebooted, so I don't know if it would have ever
recovered. All times that I did not reboot, the system eventually recovered
normalcy after a long time.
I expect Gimp to not consume X resources without bounds.
I expect that when Gimp is told to exit normally, it does so relatively
My system is:
933 Mhz P-III
512 Mb RAM
512 Mb Swap, split evenly between /dev/hda and /dev/hdb (IDE drives).
Before filing this report, I filed Bug 97917. Please read that report for
additional info. I don't think this is an OS problem; I think it's a Gimp
At least once, after the disk thrashing had stopped and Gimp was gone, X
continued to hold onto a large amount of memory. With the client gone, I
expected X to release the memory, but it did not. I suspect a memory leak in X,
though reading Bug 98978 cautions me against filing a report against X. Whoever
confirms the Gimp bug should check to see whether X has a leak, also.
just wanted to confirm that I too have experienced this bug.. I had just bought
a 512M DDR memory upgrade so that I could work with several dozens of images
that need resizing and correction for the web, and it's actually running SLOWER
than ever thanks to this problem. *argh*
I watched it with vmstat for a while, and have experienced both the slow climb,
the thrashing at exit time, and the 'hanging around' of the used vm long after
Currently I'm attempting a build of gimp 1.2.5 from source, installed into
/usr/local to see if it continues to exhibit this problem, and will report back
Created attachment 93953 [details]
vmstat output displaying problem
attached is a bunch of vmstat output from gimp 1.2.5 showing that it exhibits
the same problem as before.
I additionally tried running it with the --no-xshm command line switch, and it
does NOT exhibit this problem, so I suspect it has something to do with the X
shared memory stuff. Not knowing much else about it, I can't say with any
specificity what is causing it, but this at least opens up a good avenue for
alas I was incorrect.. using --no-xshm does NOT make the problem go away, it
merely appears to delay it a bit.. I have also compiled this 1.2.5 with
--with-shm=none and STILL the problem exists. I wish I knew what was causing it
because it's delaying a seriously large amount of paying work I need to get done.
I've been doing some major follow-up on this to the gimp's own bugzilla here:
http://bugzilla.gnome.org/show_bug.cgi?id=120782 ... interesting reading
I too have this very same problem. It seems to only occurr for me
when editing sufficiently large images. I don't have any problems
editing things that are 800x600 or thereabouts. Its especially bad
when doing a "filter pack" on a large (3000x4000) image.
This really is something that has to be solved upstream.