Gimp memory leak

[Andrei Simion]

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-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[gg-6]

On Mon, 21 Apr 2008 20:58:36 +0200, Andrei Simion <ansi@...>  
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-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Andrei Simion]

gg@... wrote:

> On Mon, 21 Apr 2008 20:58:36 +0200, Andrei Simion <ansi@...>
> 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: <$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: <$buttontexture>\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",
     "<Toolbox>/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-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Kevin Cozens-2]

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.

--
Cheers!

Kevin.

http://www.ve3syb.ca/           |"What are we going to do today, Borg?"
Owner of Elecraft K2 #2172      |"Same thing we always do, Pinkutus:
                                 |  Try to assimilate the world!"
#include <disclaimer/favourite> |              -Pinkutus & the Borg


_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Sven Neumann]

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-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Andrei Simion]

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-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Sven Neumann]

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-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Andrei Simion]

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-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Sven Neumann]

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-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Andrei Simion]

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-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Kurt Pruenner]

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.

--
Kurt Bernhard Pruenner --- Haendelstrasse 17 --- 4020 Linz --- Austria
.......It might be written "Mindfuck", but it's spelt "L-A-I-N".......
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Sven Neumann]

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-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Kevin Cozens-2]

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.

--
Cheers!

Kevin.

http://www.ve3syb.ca/           |"What are we going to do today, Borg?"
Owner of Elecraft K2 #2172      |"Same thing we always do, Pinkutus:
                                 |  Try to assimilate the world!"
#include <disclaimer/favourite> |              -Pinkutus & the Borg
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Sven Neumann]

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


_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer