Gimp memory leak
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
Gimp memory leak | Andrei Simion | 21 Apr 20:58 |
Gimp memory leak | gg@catking.net | 21 Apr 21:15 |
Gimp memory leak | Andrei Simion | 21 Apr 22:23 |
Gimp memory leak | Kevin Cozens | 21 Apr 23:22 |
Gimp memory leak | Sven Neumann | 23 Apr 00:11 |
Gimp memory leak | Andrei Simion | 29 Apr 04:06 |
Gimp memory leak | Sven Neumann | 29 Apr 10:28 |
Gimp memory leak | Andrei Simion | 29 Apr 17:21 |
Gimp memory leak | Sven Neumann | 29 Apr 21:00 |
Gimp memory leak | Andrei Simion | 30 Apr 05:34 |
Gimp memory leak | Kurt Pruenner | 30 Apr 09:33 |
Gimp memory leak | Sven Neumann | 30 Apr 11:12 |
Gimp memory leak | Kevin Cozens | 01 May 06:06 |
Gimp memory leak | Sven Neumann | 05 May 08:14 |
Gimp memory leak
Hi,
I previously reported a memory leak in Gimp 2.2.
I was told to install version 2.4 and the issue doesn't go away.
The problem is that I discovered something even worst and it does take place in both 2.2 and 2.4.
If one runs a Gimp-Perl script for a number of times, enough to use the whole physical memory, then the Gimp server crashes, it does not create the swap. That's it, no swap file is created.
I think there may be a configuration issue.
If a test script is needed I can provide it.
Thanks, Andrei
Gimp memory leak
On Mon, 21 Apr 2008 20:58:36 +0200, Andrei Simion wrote:
Hi,
I previously reported a memory leak in Gimp 2.2.
I was told to install version 2.4 and the issue doesn't go away.
The problem is that I discovered something even worst and it does take place in both 2.2 and 2.4.
If one runs a Gimp-Perl script for a number of times, enough to use the whole physical memory, then the Gimp server crashes, it does not create the swap. That's it, no swap file is created.
I think there may be a configuration issue.
If a test script is needed I can provide it.
Thanks, Andrei
That would certainly be worthwhile.
pls post.
/gg
Gimp memory leak
gg@catking.net wrote:
On Mon, 21 Apr 2008 20:58:36 +0200, Andrei Simion wrote:
Hi,
I previously reported a memory leak in Gimp 2.2.
I was told to install version 2.4 and the issue doesn't go away.
The problem is that I discovered something even worst and it does take place in both 2.2 and 2.4.
If one runs a Gimp-Perl script for a number of times, enough to use the whole physical memory, then the Gimp server crashes, it does not create the swap. That's it, no swap file is created.
I think there may be a configuration issue.
If a test script is needed I can provide it.
Thanks, Andrei
That would certainly be worthwhile.
pls post.
/gg
#!/usr/bin/perl
use Gimp qw(:auto);
use Gimp::Fu;
#use Gimp::Compat;
sub logov1 { my($text, $font, $fontsize, $fontcolor, $outlinesize, $outlinecolor, $shadowoffset, $shadowblur, $embossamount, $glowamount, $bevelamount, $texture, $alignment, $bgfile, $logowidth, $logoheight,$usebgdim,$textoffset,$vertoffset,$glowopacity, $textureopacity,$buttontexture,$buttoncolor,$buttonstyle, $backimage,$outfile) = @_;
gimp_context_push();
#print STDOUT "bgfile: \n";
if ($bgfile ne "none") {
$img = gimp_file_load($bgfile,$bgfile);
} else {
#print "creating background with $buttontexture,$buttonstyle\n";
$backgroundcolor = "#FFFFFF";
if ($backimage ne "") {
$backgroundcolorimage = gimp_file_load($backimage,$backimage);
# $backgroundcolor =
gimp_image_pick_color($backgroundcolorimage,$drawable,1,1,1,0,0,1);
} else {
$backgroundcolor = "#FFFFFF";
}
gimp_context_set_background($backgroundcolor); gimp_context_get_background();
$img = gimp_image_new($logowidth,$logoheight,RGB);
$layer =
gimp_layer_new($img,$logowidth,$logoheight,0,"Background",100,0);
gimp_image_add_layer($img,$layer,0);
gimp_layer_add_alpha($layer);
gimp_selection_all($img);
gimp_drawable_fill($layer,BACKGROUND_FILL);
$buttonlayer = gimp_layer_new($img,$logowidth,$logoheight,0,"Button layer",100,0); gimp_image_add_layer($img,$buttonlayer,0); gimp_layer_add_alpha($buttonlayer); gimp_drawable_fill($buttonlayer,TRANSPARENT_FILL); gimp_selection_none($img);
# start button style
if ($buttonstyle =~ /round/i) {
# select elipse and rectangle added together for rounded button
gimp_ellipse_select($img,$logowidth-$logoheight,0,$logoheight,$logoheight,0,1,0,0);
gimp_rect_select($img,0,0,$logowidth -
$logoheight/2,$logoheight,0,0,0);
} else {
gimp_selection_all($img);
}
# button texture if ($buttontexture ne "none") { open(LOG1, ">>/home/build/gimp/logs/gimp_steve_pm.log"); print LOG1 "Button texture: \n"; close(LOG1);
$success = 0;
($numPatterns, @pattern_list) = gimp_patterns_get_list('');
foreach $pattern (@pattern_list) {
#print STDOUT $pattern . "\n";
if ($pattern eq $buttontexture) {
$success = 1;
#print STDOUT "\n\nsuccess [$buttontexture]\n\n";
break;
}
}
if ($success) {
gimp_context_set_pattern($buttontexture);
#gimp_edit_bucket_fill($buttonlayer,PATTERN_FILL,0,100,0,0,0,0);
gimp_edit_bucket_fill($buttonlayer,PATTERN_BUCKET_FILL,0,100,0,0,0,0);
plug_in_colorify($img,$buttonlayer,$buttoncolor);
}
}
if (0) {
$success = 0;
@pattern_list = gimp_patterns_get_list();
foreach $pattern (@pattern_list) {
if ($pattern eq $buttontexture) {
$success = 1;
#print "\n\nsuccess $buttontexure\n\n";
break;
}
}
if ($success) { $textureimg = gimp_image_new($logowidth,$logoheight,GRAY);
$texturelayer =
gimp_layer_new($textureimg,$logowidth,$logoheight,GRAY-IMAGE,"Texture
layer",$textureopacity,0);
$texturelayer2 =
gimp_layer_new($img,$logowidth,$logoheight,RGB-IMAGE,"Texture
layer",$textureopacity,0);
gimp_drawable_fill($texturelayer,PATTERN_FILL); gimp_drawable_fill($texturelayer2,PATTERN_FILL); gimp_layer_add_alpha($texturelayer); gimp_layer_add_alpha($texturelayer2);
gimp_context_set_pattern($buttontexture);
gimp_edit_bucket_fill($texturelayer,2,0,$textureopacity,255,0,0,0);
gimp_image_add_layer($textureimg,$texturelayer,0);
gimp_image_convert_rgb($textureimg);
gimp_selection_all($textureimg); gimp_edit_copy($texturelayer);
$texturelayer2 = gimp_edit_paste($texturelayer2,0); gimp_selection_layer_alpha($buttonlayer); gimp_selection_invert($img); gimp_edit_cut($texturelayer2); gimp_selection_none($img);
gimp_layer_set_opacity($texturelayer2,$textureopacity);
$buttonlayer =
gimp_image_merge_down($img,$texturelayer2,2);
}
} # end if buttontexture
# end button texture
$background = gimp_image_merge_visible_layers($img,1);
} # end else not exist bgfile
if ($usebgdim) { $logoheight = gimp_image_height($img); $logowidth = gimp_image_width($img); }
if (! gimp_drawable_is_rgb(gimp_image_active_drawable($img)) ) { gimp_image_convert_rgb($img); }
gimp_context_set_foreground($fontcolor);
# Create the text layer. Using -1 as the drawable creates a new layer.
my $text_layer = gimp_layer_new($img,$logowidth,$logoheight,0,"text_layer",0,0); gimp_image_add_layer($img,$text_layer,0); gimp_layer_add_alpha($text_layer);
$img->gimp_selection_none;
Gimp::Fu::save_image($img, $outfile);
$img->gimp_image_delete;
gimp_context_pop();
#return $img;
}
# register the script
register "logov1",
"logo",
"logo",
"A",
"B",
"1999-06-09",
"/Xtns/Web/SS Logo",
"",
[
[PF_STRING, "text", "text", "sitesell rules"],
[PF_FONT, "font", "font", "Utopia Bold"],
[PF_INT, "fontsize", "Font Size", "70"],
[PF_COLOR, "fontcolor","Font Color", [255,200,0]],
[PF_INT, "outlinesize", "Outline Size", "3"],
[PF_COLOR, "outlinecolor", "Outline Color", [0,0,0]],
[PF_INT, "shadowoffset", "Drop Shadow Offset", "0"],
[PF_INT, "shadowblur", "Drop Shadow Blur","0"],
[PF_INT, "embossamount", "Emboss Amount", "0"],
[PF_INT, "glowamount", "Glow Amount", "0"],
[PF_INT, "bevelamount", "Bevel Amount", "0"],
[PF_STRING, "texture", "Texture", "none"],
[PF_STRING, "alignment","Alignment", "left"],
[PF_STRING, "bgfile", "Background file", "none"],
[PF_INT, "width", "Width", "725"],
[PF_INT, "height", "Height", "80"],
[PF_INT, "usebgdim", "Use BG Image Dimensions", "0"],
[PF_INT, "textoffset", "Offset for text to start", "0"],
[PF_INT, "vertoffset", "Vertical offset for text to start", "0"],
[PF_INT, "glowopacity", "Opacity of glow effect", "75"],
[PF_INT, "textureopacity", "Opacity of texture", "50"],
[PF_STRING, "buttontexture", "button texture", "none"],
[PF_COLOR, "buttoncolor", "button color", [255,0,0]],
[PF_STRING, "buttonstyle", "button style", "roundoutline"],
[PF_STRING, "backimage","Background color file",""],
[PF_STRING, "outfile", "Output file name","/tmp/logov1.gif"]
],
\&logov1;
# Handle over control to gimp
exit main();
#main();
Gimp memory leak
Andrei Simion wrote:
If one runs a Gimp-Perl script for a number of times, enough to use the whole physical memory, then the Gimp server crashes, it does not create the swap. That's it, no swap file is created.
I think there may be a configuration issue.
If a test script is needed I can provide it.
You should add this latest information to the bug report at http://bugzilla.gnome.org/show_bug.cgi?id=525016
If you have a script which demonstrates the problem, attach it to the bug report. Note that I said to *attach* the script to the report. Don't just paste the script in to the text of the bug report.
In your update, include the version(s) of GIMP you are using, which Linux distro (and version) you are using, and the settings of the Preference items under "Resource Consumption".
This past weekend I ran some tests using logov1 from inside GIMP and it worked perfectly. After each invocation of the script, there was no swap file left over. It certainly showed no signs of any leak. Perhaps the problem occurs when running a script via the Perl server. I haven't done any rigorous testing of running scripts using Perl server yet.
Gimp memory leak
Hi,
On Mon, 2008-04-21 at 14:58 -0400, Andrei Simion wrote:
If one runs a Gimp-Perl script for a number of times, enough to use the whole physical memory, then the Gimp server crashes, it does not create the swap. That's it, no swap file is created.
This may very well be a memory leak in Gimp-Perl. Have you run this in valgrind with leak-check enabled? That should give you a good idea of where the leak actually is.
If a test script is needed I can provide it.
Gimp-Perl isn't actively maintained at the moment, so a Perl script doesn't help us much. Can you reproduce this issue with a Script-Fu or Python script?
Sven
Gimp memory leak
Hi,
Sven Neumann wrote:
This may very well be a memory leak in Gimp-Perl. Have you run this in valgrind with leak-check enabled? That should give you a good idea of where the leak actually is.
This is the valgrind report:
==31947==
==31947== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 1)
==31947== malloc/free: in use at exit: 47,785 bytes in 1,684 blocks.
==31947== malloc/free: 1,246,403 allocs, 1,244,719 frees, 23,095,553
bytes allocated.
==31947== For counts of detected errors, rerun with: -v
==31947== searching for pointers to 1,684 not-freed blocks.
==31947== checked 207,552 bytes.
==31947==
==31947== 50 (16 direct, 34 indirect) bytes in 1 blocks are definitely
lost in loss record 1 of 5
==31947== at 0x4A05809: malloc (vg_replace_malloc.c:149)
==31947== by 0x455F4A: xmalloc (in /bin/bash)
==31947== by 0x41F103: (within /bin/bash)
==31947== by 0x421273: yyparse (in /bin/bash)
==31947== by 0x41B091: parse_command (in /bin/bash)
==31947== by 0x41B14B: read_command (in /bin/bash)
==31947== by 0x41B38D: reader_loop (in /bin/bash)
==31947== by 0x41AE08: main (in /bin/bash)
==31947==
==31947== LEAK SUMMARY:
==31947== definitely lost: 16 bytes in 1 blocks.
==31947== indirectly lost: 34 bytes in 1 blocks.
==31947== possibly lost: 0 bytes in 0 blocks.
==31947== still reachable: 47,735 bytes in 1,682 blocks.
==31947== suppressed: 0 bytes in 0 blocks.
==31947== Reachable blocks (those to which a pointer was found) are not
shown.
==31947== To see them, rerun with: --show-reachable=yes
This is what I obtained after the Gimp server crashed. That's it, it doesn't create the swap file after the memory allocated for it finishes. Is this a configuration problem?
Andrei
Gimp memory leak
Hi,
On Mon, 2008-04-28 at 22:06 -0400, Andrei Simion wrote:
This is what I obtained after the Gimp server crashed. That's it, it doesn't create the swap file after the memory allocated for it finishes. Is this a configuration problem?
Sorry, but I don't understand that question. You are aware of how GIMP's swapping works and how it relates to the configured size of the tile-cache, aren't you? I have the impression that there are some basic misunderstandings here.
Sven
Gimp memory leak
Sven Neumann wrote:
Hi,
On Mon, 2008-04-28 at 22:06 -0400, Andrei Simion wrote:
This is what I obtained after the Gimp server crashed. That's it, it doesn't create the swap file after the memory allocated for it finishes. Is this a configuration problem?
Sorry, but I don't understand that question. You are aware of how GIMP's swapping works and how it relates to the configured size of the tile-cache, aren't you? I have the impression that there are some basic misunderstandings here.
OK, the tile-cache-size refers to the amount of pixel data. But the question still remains: why the Gimp could crash?
I noticed that the memory used by the Gimp server when batch generating images goes higher and higher and after no physical memory is left, then the Gimp server crashes.
Sven
Gimp memory leak
Hi,
On Tue, 2008-04-29 at 11:21 -0400, Andrei Simion wrote:
I noticed that the memory used by the Gimp server when batch generating images goes higher and higher and after no physical memory is left, then the Gimp server crashes.
That is the usual behavior of all applications based on GLib. In an out-of-memory situation, the application exits with an error message. This is probably what you are calling a 'crash'. This can usually be avoided by setting the tile-cache size reasonably and by providing enough virtual memory.
The memory usage during batch processing should remain pretty much constant though. This indicates that there is likely a memory leak somewhere. valgrind should help to locate the problem.
Sven
Gimp memory leak
Hi,
Sven Neumann wrote:
That is the usual behavior of all applications based on GLib. In an out-of-memory situation, the application exits with an error message. This is probably what you are calling a 'crash'. This can usually be avoided by setting the tile-cache size reasonably and by providing enough virtual memory.
The memory usage during batch processing should remain pretty much constant though. This indicates that there is likely a memory leak somewhere. valgrind should help to locate the problem.
This is the problem. The memory used by the Gimp process grows constantly. After finishing up the physical memory, it does not create the swap file.
On Gimp 1.2 the swap file was created, but it kept growing. On 2.2 and 2.4, no swap file is created and the Gimp process terminates.
What size should I set for the tile-cache? Currently I use a value of 128 MB.
Andrei
Gimp memory leak
Andrei Simion wrote:
This is the problem. The memory used by the Gimp process grows constantly. After finishing up the physical memory, it does not create the swap file.
Well, like it has been said before the swap file is for the tile cache. If something else is leaking memory (due to unfreed mallocs or what have you) GIMP of course won't create a swap file, it'll just balloon the process and run out of mem at some point...
Don't confuse the GIMP swapfile with a general-purpose swapfile like the one your OS is using.
Gimp memory leak
Hi,
On Tue, 2008-04-29 at 23:34 -0400, Andrei Simion wrote:
This is the problem. The memory used by the Gimp process grows constantly. After finishing up the physical memory, it does not create the swap file.
We have run a lot of tests to check for memory leaks. There are currently no known leaks. But of course we might have missed one. That's why it would be nice if you could isolate the leak or provide enough details so that we can reproduce the problem. So far you failed to do that.
What size should I set for the tile-cache? Currently I use a value of 128 MB.
That's explained at http://gimp.org/unix/howtos/tile_cache.html
Sven
Gimp memory leak
Sven Neumann wrote:
That's
why it would be nice if you could isolate the leak or provide enough details so that we can reproduce the problem. So far you failed to do that.
Andrei may not have isolated the leak to one or two PDB calls but he has provided a script which shows the growing memory usage problem. My tests appear to show GIMP's memory usage growing even from running a Script-Fu logo script. The ps command reports increasing numbers for VSZ and RSS after each time a logo script is run even after the display window closed.
Something GIMP uses seems to be leaking memory if it isn't in GIMP itself. Sven looked at one of the valgrind reports I captured and still felt the leak was not in GIMP. I will be attaching one of the valgrind reports to the bug report soon.
BTW, some of the information from this message thread should be going into the bug report.
Gimp memory leak
Hi,
On Thu, 2008-05-01 at 00:06 -0400, Kevin Cozens wrote:
Andrei may not have isolated the leak to one or two PDB calls but he has provided a script which shows the growing memory usage problem. My tests appear to show GIMP's memory usage growing even from running a Script-Fu logo script. The ps command reports increasing numbers for VSZ and RSS after each time a logo script is run even after the display window closed.
Looking at the output of ps is not a suitable way to detect a memory leak. The main reason is that both libc and glib are using memory pools. You should really use valgrind or some other memory debugger. And you should set the environment variable GSLICE to always-malloc when you are doing that.
Sven