GNOME Bugzilla – Bug 55686
Gimp swap file grows unbounded, and is not flushed
Last modified: 2009-08-15 18:40:50 UTC
I'm hitting some swap file problems: I set the tile cache to 75MB, undo levels to 4, but when I edit even smaller images (1600x1300 24bit), the gimp swap file grows in a seemingly unbounded way, past 30MB in size and growing until I quit. Then, when I quit the Gimp, I get a Gimp-warning that the swap file is not empty, and then a large list of ranges. Steps to reproduce: I have a 1600x1300 image, a composite of four scanned photos, and in creating individual files, I do this: 1) Apply a sharpen filter 2) Select a region of the composite, ~800x600 3) Copy to the clipboard 4) File->New.. this gives a default size equal to the clipboard contents 5) Paste into the new window 6) Anchor the selection 6) Rotate the new window by 270 degrees. 7) File->Save... the new window 8) Close the new window 9) Repeat for the other three photographs in the composite When I'm finished, I close the composite, and the cache is still quite large, and I get warnings when I quit the Gimp about the remaining cache contents. Another odd phenomenon is that while the composite is open, even if I'm not doing anything, the cache is growing by about 30K per second.
Also seen on RH Linux 7.1 and SGI IRIX 6.5.x using Mr. Pavel's procedure. Tile Cache size = 32 meg on both platforms; both platforms running current CVS version of 1.2.1 GRO
Created attachment 632 [details] Stack traces showing allocation/release of tile managers
The following (somewhat shorter) list of actions also reliably give rise to unreleased tiles. One gets a visible manifestation of this when running Gimp with a small (30m tile cache) and typing % limit memoryusage 30m in the csh style shell prior to starting Gimp. This forces tiles to live on the disk cache instead of in memory, where they are breathing upon application exit. 1. Open image from a file 2. Copy image 3. Create new image (File -> new) 4. Paste into new image 5. Anchor pasted floating layer 6. Close new image 7. Close original image 8. Quit application Under this flow of events, the tile managers for the background layers of both the original and new image are never freed, contributing to unfreed swap tiles. Set watch points in app/tile_manager.c [CVS 1.24 gimp-1-2 branch] at tile_manager_new() [line 31] and tile_manager_destroy() [line 65]. which dumped stack traces when they were hit. for brevity, the GTK/main loop parts of the stack traces have been removed. See prior attachment. (id=632) 09-June-2001. Salient remarks: by step 6, ten tile managers are extant in the application. They are, in order of allocation: 1. 0x10884450 Selection Mask (Image 0) [destroyed 17] 2. 0x1088c100 Background (Image 0) 3. 0x10a414e8 Projection (Image 0) [destroyed 16] 4. 0x10c970b8 Edit Copy (Image 0) [destroyed 18] 5. 0x10873ad8 Selection Mask (Image 1) [destroyed 15] 6. 0x10a4e208 Background (Image 1) 7. 0x10c97140 Projection (Image 1) [destroyed 14] 8. 0x112ea898 Pasted Layer (Image 1) [destroyed: 12] 9. 0x110a6c80 Floating Anchor Attach (Image 1) [destroyed: 11] 10. 0x103e3240 Layer Anchor (Image 1)[destroyed: 13] They are released when first the new image, then the old image, then the application itself are closed. [Image 1 Close] 11. 0x110a6c80 Floating Anchor Number 9 (tiles 144 ) 12. 0x112ea898 Pasted Layer (Image 1) Number 8 (tiles 144) 13. 0x103e3240 Layer AnchorPasted Layer (Image 1) Number 10 (tiles 144) 14. 0x10c97140 Projection (image 1) Number 7 (tiles 144) 15. 0x10873ad8 Selection Mask (image 1) Number 5 (tiles 144) [Image 0 Close] 16 0x10a414e8)Projection (image 0) Number 3 (tiles 144) 17. 0x10884450 Selection mask copy Number 1 (tiles 144) [Gimp Close] 18. 0x10c970b8 Edit Copy Number 4 (tiles 144)
After I submitted a report to the gimp-developer news list, (11-June-2001) Sven Neumann proposed this patch. -------------------------------------------------- Hi, Big, Fat Piggy Gimp Fans, here's a very small patch that should fix our huge leak: Index: app/gimpimage.c =================================================================== RCS file: /cvs/gnome/gimp/app/Attic/gimpimage.c,v retrieving revision 1.121.2.1 diff -u -r1.121.2.1 gimpimage.c --- app/gimpimage.c 2000/12/27 17:55:19 1.121.2.1 +++ app/gimpimage.c 2001/06/12 00:00:57 @@ -1456,7 +1456,7 @@ for (list = gimage->layers; list; list = g_slist_next (list)) { layer = (Layer *) list->data; - layer_delete (layer); + layer_unref (layer); } g_slist_free (gimage->layers); g_slist_free (gimage->layer_stack); @@ -1472,7 +1472,7 @@ for (list = gimage->channels; list; list = g_slist_next (list)) { channel = (Channel *) list->data; - channel_delete (channel); + channel_unref (channel); } g_slist_free (gimage->channels); } Given the confusing API used here it's not surprising that this could happen. Gimp HEAD already had this hole plugged, but not because someone found and fixed it, but because the code has already become much cleaner and we avoid to wrap around basic functions like gtk_object_[ref|unref]. I don't consider this a clean solution but since it's a very small change, we should be able to evaluate easily if it is a correct fix. A better fix can be found in CVS HEAD, but I would prefer not to do too much changes to 1.2 if it can be avoided. I haven't tested the patch much so far, so please torture it. Salut, Sven --------------------------------------------------- I've applied this to the current (11-06-2001) CVS of gimp-1-2; preliminary results look promising, but I plan to "torture" it through the Perl-Server this weekend, using something based on Marc Lehmann's perl snippet that he used to illustrate the leak (See around his 01-June-2001 "Perl Server" mail)
I am no longer seeing tile managers from persisting layers and channels for some time now. (three weeks); I believe Sven's patch addresses the immediate issue that I posted in the news group. I am less confident about the "odd phenomenon" also reported originally by Mr. Pavel. I have not characterized it; building a debug GTK and enabling it to dump objects reports random UI elements not being freed, but I haven't isolated underlying causes. However, since the characterized and isolated leak cited in this report has been addressed, I believe this one can be closed. Be good, be well Garry