RSS/Atom feed Twitter
Site is read-only, email is disabled

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.

14 of 14 messages available
Toggle history

Please log in to manage your subscriptions.

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
Andrei Simion
2008-04-21 20:58:36 UTC (about 17 years ago)

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

gg@catking.net
2008-04-21 21:15:48 UTC (about 17 years ago)

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

Andrei Simion
2008-04-21 22:23:31 UTC (about 17 years ago)

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();

Kevin Cozens
2008-04-21 23:22:47 UTC (about 17 years ago)

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.

Sven Neumann
2008-04-23 00:11:37 UTC (about 17 years ago)

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

Andrei Simion
2008-04-29 04:06:01 UTC (about 17 years ago)

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

Sven Neumann
2008-04-29 10:28:44 UTC (about 17 years ago)

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

Andrei Simion
2008-04-29 17:21:12 UTC (about 17 years ago)

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

Sven Neumann
2008-04-29 21:00:47 UTC (about 17 years ago)

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

Andrei Simion
2008-04-30 05:34:06 UTC (about 17 years ago)

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

Kurt Pruenner
2008-04-30 09:33:53 UTC (about 17 years ago)

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.

Sven Neumann
2008-04-30 11:12:13 UTC (about 17 years ago)

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

Kevin Cozens
2008-05-01 06:06:44 UTC (about 17 years ago)

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.

Sven Neumann
2008-05-05 08:14:35 UTC (almost 17 years ago)

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