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): gimp-1.2.3-16 XFree86-4.3.0-2 How reproducible: 100% 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 normally. 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 quickly. 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 problem. 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 exit. 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.
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 exploration.
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.