Bug 99485 - Gimp does not release X resources; thrashes badly on exit
Gimp does not release X resources; thrashes badly on exit
Product: Red Hat Linux
Classification: Retired
Component: gimp (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Matt Wilson
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2003-07-21 04:41 EDT by Craig Lawson
Modified: 2007-04-18 12:55 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-02-21 11:39:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
vmstat output displaying problem (6.87 KB, text/plain)
2003-08-26 13:59 EDT, Scott R. Godin
no flags Details

  None (edit)
Description Craig Lawson 2003-07-21 04:41:44 EDT
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):

How reproducible:

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 
Actual results:
  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.

Expected results:
  I expect Gimp to not consume X resources without bounds.
  I expect that when Gimp is told to exit normally, it does so relatively 

Additional info:
  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.
Comment 1 Scott R. Godin 2003-08-26 13:08:29 EDT
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
any findings. 

Comment 2 Scott R. Godin 2003-08-26 13:59:39 EDT
Created attachment 93953 [details]
vmstat output displaying problem
Comment 3 Scott R. Godin 2003-08-26 14:01:00 EDT
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
Comment 4 Scott R. Godin 2003-08-26 17:04:04 EDT
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. 
Comment 5 Scott R. Godin 2003-09-02 15:50:45 EDT
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 
Comment 6 Steve Lacy 2004-01-13 03:20:27 EST
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. 
Comment 7 Nils Philippsen 2004-02-21 11:39:29 EST
This really is something that has to be solved upstream.

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