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: xorg-x11-0.0.6.6-0.0.2004_03_11.9 gimp-2.0.0-2 FC1 machine: XFree86-4.3.0-55 gimp-2.0.0-3 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.
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.
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. perhaps. Thanks guys.
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
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 592MB). 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.
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 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.
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: http://bugs.freedesktop.org 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"