GNOME Bugzilla – Bug 120782
gimp-1.2 leaks memory
Last modified: 2009-08-15 18:40:50 UTC
another bug has been filed on this issue at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=99485 with full details running gimp with --no-xshm makes the problem go away. for the next release of gimp (1.2.6?) would someone PLEASE add the ability to pass --no-xshm as a pass-thru switch to gimp-remote until this problem is resolved ?
*sigh* no, I was wrong. --no-xshm just delays it a bit. it still happens with or without it. I've also compiled this version with --with-shm=none and it's STILL happening. I wish I knew with any specificity what was causing the problem, as it's seriously delaying a rather large amount of work I need to be doing.
There is that subtle difference between shm and xshm. The configure switch --with-shm=none is not at all related to X shared memory.
I had a look at the source and I don't think that GIMP is leaking any X resources. If at all it would be a GTK+/GDK issue. What version of GTK+ are you using? what exactly makes you think that GIMP is leaking X reources? Is there a way we can reproduce this?
11:49am {4} pcp01501167pcs:/home/webdragon>$ rpm -qa | egrep -i '^gtk' |sort gtk+-1.2.10-25 gtk+-devel-1.2.10-25 gtk-doc-0.10-4 gtk-engines-0.11-16 gtk2-2.2.1-4 gtk2-devel-2.2.1-4 gtk2-engines-2.2.0-2 gtkam-0.1.7-3 gtkglarea-1.2.2-16 gtkhtml-1.1.9-0.9 gtkhtml-devel-1.1.9-0.9 gtkhtml2-2.2.0-5 I tried compiling 1.3.18 (and am now using 1.3.19). for a batch of 5-8 700K files, the memory usage of the app is MUCH more normal. Opening this many images in 1.2.3 - 1.2.5 and beginning some work on them in order which involved making the same change to each image before moving on to the next step: crop slightly smaller, adjust hue-saturation about 45, adjust levels about 1.35 in the midtone, resize from 2048x1536@72dpi to 400x300@72dpi, sharpen about 55, add a small transparent watermark and fade it in, save as jpeg 65%. now, If I stop somewhere in the middle, I can literally watch swap usage climb steadily, _while gimp is idle!_, using (vmstat 1). if I work with about 3-4 image sets consisting of 4-8 images each, and then quit the gimp, it thrashes for anywhere between 3-15 minutes, freezing the mouse and not letting me do anything else, until it's done. I tried adjusting the undo levels, I tried adjusting the tile cache size, I tried ticking the "conservative memory usage" checkbox, I tried adding a 512M DDR stick upgraded from the 128M DDR stick, I tried using ulimit. 1.3.18 with about 5-6 <700K images open uses about what RAM I'd expect according to top and pretty much stays consistent. 1.2.x winds up using about 2-3 times that when all's said and done over the couse of a few edits. How would YOU explain it? I'm totally at a loss. There is also the bugzilla filed at redhat, above, with further details from someone else who has also seen this happen.
Which X server version and driver?
standard X server for redhat 9, 4.3.0 using the nvidia driver NVIDIA Linux x86 nvidia.o Kernel Module 1.0-4496 Riva TNT2 video card. 512MB PC2700 DDR (one stick). Duron 1.1Ghz processor with Abit KG-7 Lite motherboard. I don't know what the original guy who posted this to the redhat bugzilla list was using.. you might also ask him. Anything else you need to know?
See if the problem happens without the binary only nvidia driver. That driver has a history of having strange bugs.
Created attachment 19654 [details] test-case examples with descriptive text
I've added a somewhat lengthy test case. the image-editing steps are the same as described above. files saved in /tmp in all cases. let me know if you need further info.
This report is obviously confusing two problems. Despite the fact that the problem cannot be reproduced here, the bug-report should limit itself to the problem mentioned in the summary and that is X resources. If there are problems with GIMP not releasing memory it allocated, a new bug report needs to be opened for this. And please, if you make any tests, use the latest released version (1.2.5).
perhaps a better subject line is in order.. but I merely copied over the original subject from the redhat bugzilla report made by someone else (linked above at top of this report). I DID try 1.2.5 and experienced the exact same problem illustrated in the attachment I made earlier. 1.3.18/19's RAM usage for 6-8 700K-and-under files is MUCH more in line with what I would expect the program to use. VM doesn't get out of hand. there is not the thrashing that I experience under 1.2.x. the problem is not so much that it's not releasing the memory. it's that it is using way too much, and slowly creeping into more and more and more and more swap over time until you've damn near filled swap. EVEN with gimp just idling in the background. This is under red hat 9, with gimp 1.2.3 - 1.2.5. both experience the same problem, for me. 1.2.5 was the FIRST thing I tried when I noticed the problem. I would have retested above using 1.2.5 but I'd overwritten it with the working 1.3.19 since I HAD to get work done. When I filed the above attachment I used the only 1.2.x version still installed -- the one that comes with my distro of red hat linux 9. You might try contacting the person who made the original bugzilla.redhat.com report and see if he can give you additional feedback. I desperately need gimp to work consistently right now so I can get all this work done, or I'd be happy to install and test a dozen versions if necessary. Fortunately 1.3.x is working very nicely for me right now (great work guys. looks lovely, is faster, remembers previous settings in save-as jpg dialog (THANKS!); I can't tell you how happy 1.3.x made me)
How did you manage to overwrite gimp-1.2 with gimp-1.3? The two versions coexist nicely, there are no clashing files.
I have just run gimp-1.2.5 under memprof and performed the steps you described. There are a few very small leaks reported but after processing two images these leaks sum up to less than 300 bytes so it's probably not worth to attempt to close these in the stable branch. There must be something terribly wrong with one of the libraries you are using. Please, if possible, run gimp under memprof (or another memory profiler of your choice) and report back.
Oh, in case you are using a GTK+ theme, you should definitely try if the problem goes away if you switch back to the default GTK+ theme (or rather no theme). Your problem might very well be a massive leak in a gtk+ theme engine.
Sven: I didn't exactly overwrite them, however cd /usr/local/bin; ln -s gimp-1.3 gimp; ln -s gimp-remote-1.3 gimp-remote etc, I had to remove the symlinks to the old gimp version, and it made more sense since I didn't plan to use 1.2.5 after I saw the problem continue, to just uninstall it. running memprof on only two images, where in my uploaded test-case I had worked with at least 18 images before I really started to see things take off, is a bit of an 'early escape'. (can't think of the right phrase but I think you'll get what I mean) and no I'm not using any particularly odd gtk theme. just straight blackbox 0.65.0. I don't think I've even messed with the default theme for gtk ever, and this is a clean install of redhat 9 (though upgraded in some ways with additional software, I haven't done much with the libraries other than upgrade libgd, but THAT is only in /usr/local so that I could link it to the latest GD.pm perl module) I'll try running memprof on a 1.2.5 and see what I can come up with after running through a series of files.
If there would be a major leak it would already show up in memprof when working on the first image. I am not going to waste my time with this any longer until you can prove that gimp is the cause of the problem. I have no idea what blackbox is but you should definitely check the theme you are using. AFAIK RedHat comes with a default GTK+ theme.
your proof has arrived. see the following gimp-1.2.5-memorytrail, mwm-gimp-1.2.5--1.3.19-memorytrail, and memprof.tgz attachments, in this order. blackbox is a window manager similar to windowmaker, and was forked to form fluxbox, openbox and waimea. very low memory, very clean. currently at 0.65.0 on sourceforge [http://www.sf.net/projects/blackboxwm/] The problem has ZILCH to do with any theme. I switched to MWM (similar to TWM) for my window manager to perform these following tests. I don't think ANYONE can argue with the results, considering I also compare them with 1.3.19 in use doing the EXACT same tasks. gimp-1.2.x memory use is thru the roof, while 1.3.19 is EXACTLY what you'd expect for such small files. see for yourself.. the proof is in the output. the memprof.leak seems to show a steady stream of 168 bytes slowly leaked over time. where it's coming from I dunno, but if you leave it running long enough eventually it consumes a hella lot. see the attachments I'm about to add. -scott
Created attachment 19670 [details] test case number two.
Created attachment 19671 [details] test case numbers three and four
Created attachment 19672 [details] memprof results from test cases two and three
files two and three are plain text, file four should be named 'memprof.tgz' but your bugzilla script attempts to send me a file named 'showattachment.cgi' which when tested by /usr/bin/file says it is gzipped .. one presumes this works properly if you tar zxf the file. let's try it. >$ tar tzvf /tmp/showattachment.cgi -rw------- webdragon/users 1417226 2003-09-02 11:50:27 memprof.leak -rw------- webdragon/users 92418 2003-09-02 11:50:34 memprof.out -rw------- webdragon/users 1112522 2003-09-02 12:48:43 memprof2.leak -rw------- webdragon/users 62067 2003-09-02 12:49:05 memprof3.leak -rw------- webdragon/users 1112522 2003-09-02 14:29:57 memprof4.leak -rw------- webdragon/users 405042 2003-09-02 14:30:18 memprof5.leak yep, it's there allright. someone needs to fix the script.
But have you tried switching the GTK+ theme? You mention the window manager, but this is completely unrelated to the GTK+ theme. - If you have at least some bits of a GNOME1 environment, you can start the GNOME Control Center and use the Theme Selector to select one of the available themes. - If you do not have any GNOME stuff, check if you have a file called .gtkrc in your home directory. If yes, check what is inside. If it contains any include statements, it may be loading a theme for all GTK+ applications. Try to remove that stuff and see if the memory usage is different.
If you don't use gimp-remote, do you see the same behavior?
This is not at all a proof that the problem is in the GIMP code. From a quick glimpse over the memprof output, it seems that GIMP would be leaking GDK cursors. However this leak should show up in my memprof sessions then as well. The code in question basically looks like this: (app/cursorutil.c) cursor = gdk_cursor_new (cursortype); gdk_window_set_cursor (win, cursor); gdk_cursor_destroy (cursor); This looks sane to me.
manish: if I don't use gimp-remote the problem doesn't manifest itself, since I can't then re-use the already running gimp process to open the *next* set of 6-8 images, which is possibly why this hasn't been caught yet. Raphael, sven: I both switched themes (to Simple and ThinIce) using gnome-control-center even though I don't use gnome.. and also tried deleting the .gtkrc entirely and falling back on the default redhat theme, BlueCurve. problem still manifests itself. vmstat 1 still shows a steady progression outwards: 1 0 0 166196 11092 13148 76276 0 228 0 260 191 368 0 1 99 2 0 0 166196 11092 13148 76276 0 0 0 0 176 231 0 0 100 1 0 0 166424 11092 13148 76276 0 228 0 228 177 250 1 0 99 1 0 0 166424 11092 13148 76276 0 0 0 0 177 261 0 0 100 1 0 0 166652 11092 13148 76276 0 228 0 228 178 271 0 0 100 1 0 0 166652 11084 13156 76276 0 0 0 20 191 276 0 0 100 1 0 0 166880 11084 13148 76284 0 228 0 228 178 273 0 0 100 1 0 0 166880 11084 13148 76284 0 0 0 0 179 273 0 0 100 I'm open to suggestions. particularly since 1.3.19 doesn't exhibit these problems.
What are you doing with gimp-remote that you can't do in the GUI? You can open multiple files at once by doing Ctrl or Shift click in the file selector list.
what I was doing with gimp-remote that I can't do without it, Manish, is that I was working on 5-8 images at once, for a set (so that all changes to the set are self-consistent WITH the rest of the set), and then opening a new set of 5-8 images, and then a new set of 5-8 images, and so on. Usually I'll have somewhere in the vicinity of 150 image files to work on, and it makes little sense to have to quit and restart the app all the time. Or maybe I'm just too used to how Photoshop works on the Macintosh to get used to having to quit and restart the gimp after editing every single image I work on before starting on another. I've pretty much given up on GIMP at this point as it's just not ready for a production environment. 1.3.x has improved greatly, but still isn't ready IMHO. Not when I can do things much faster on a 7 year old Macintosh running OS 8.6 with less than 1/2 the RAM of my linux box, and around 1/3 the Mhz coupled to a 44Mhz bus speed on the old motherboard. I kid you not.
Hmm, still noone seems to be able to reproduce this problem. I am tempted to close this report.
Should the fact that memory usage increase while idle be a tip off that threads are enabled? Does threading work at all in gimp-1.2.x? (iirc, it doesn't).
How could threads be causing this? I don't see anything that points towards threads but I am sure the bug reporter would have told us if he enabled an option that is marked as being experimental and unsupported.
I too am able to reproduce this problem (gimp causing X11 to bloat, even after exiting the gimp) Its been happening ever since I upgraded from RH8 to FedoraCore1. My take on it is that its actually a bug in X11, since thats the program thats bloating. After the gimp has exited, and X11 should notice and free up any associated resources, right? (mabye improper usage of xshm would cause this to happen, and obviously that would be a bug in the GTK libraries, as the GIMP doesn't make xshm calls directly) Here's what I'm running: gtk2-2.2.4-5.1 gtk-engines-0.12-1 gtk2-engines-2.2.0-3 gtk+-devel-1.2.10-28.1 gtk+-1.2.10-28.1 gtk2-devel-2.2.4-5.1 gimp-1.2.5-1 XFree86-4.3.0-42 The video card is a vesa-compliant onboard chipset, and I'm using the vesa X11 drivers, so thats all "out of the box" and not related to any 3rd party drivers. Yes, this is a very annoying problem, and makes it nearly impossible to edit large images. Its easiest for me to reproduce using "top" (and pressing "M" to sort by memory usage) then using the "Filter Pack" of GIMP. As I click on each color modification in the filter pack, the memory usage goes up by megabytes, but only if the image I'm editing is sufficiently large. I'm sure any ~3000x4000 image would do the trick.
It it almost possible that the filterpack plug-in leaks X11 resources since it doesn't use any GDK functions that allocate X11 resources. The only conclusion I have is either a bug in GDK or in your X server.
You could try running xrestop (http://freedesktop.org/Software/xrestop). Perhaps this gives a hint on what's going on here.
Did xrestop help to track down this problem?
We are about to release 2.0 and are not going to put any further efforts into gimp-1.2, so this problem in 1.2 will not get any further attention. I am closing this report.