Hi,

"Jared Whiting" writes:

The fix included with Gimp 2.0.5 ("work around file-descriptor leak in Pango (#143542, #148997)") appears to have resolved most of the memory leak issues I was running into with my Gimp Perl scripts and the gimp_text_fontname function (thanks to those involved!). I do still notice a memory increase however, based on running test scripts and observing the results with top.

The increase is sporadic and difficult to pinpoint, however I am able to consistently increase the memory in use by the Gimp instance by the following actions with a test script:

1) Start up a new instance of Gimp with the perl server running. 2) Execute the following from a perl script:

Gimp::init; Gimp::set_trace(TRACE_ALL);
my $img = gimp_image_new(300, 200, 0); $img->gimp_image_undo_disable;

my $layer = gimp_layer_new($img, 300,200,RGB, "Layer 1", 100, NORMAL_MODE);
gimp_image_add_layer($img, $layer, -1); $layer = gimp_layer_new($img, 300,200,RGB, "Layer 2", 100, NORMAL_MODE); gimp_image_add_layer($img, $layer, -1); $layer = gimp_layer_new($img, 300,200,RGB, "Layer 3", 100, NORMAL_MODE); gimp_image_add_layer($img, $layer, -1); $layer = gimp_layer_new($img, 300,200,RGB, "Layer 4", 100, NORMAL_MODE); gimp_image_add_layer($img, $layer, -1); $layer = gimp_layer_new($img, 300,200,RGB, "Layer 5", 100, NORMAL_MODE); gimp_image_add_layer($img, $layer, -1);

$img->gimp_image_undo_enable; gimp_image_delete($img);
Gimp::end;

3) After the above code is executed, the Gimp instance will consistently use about 140k more memory that does not get released. Re-running the code doesn't result in any permanent increase, but if I add the following piece of code to the above and execute it about 140k more is permanently added to the memory being used by Gimp:

my $text_layer = gimp_text_fontname($img,-1,0,0,"Testing testing", 0, 0, 14, 0, "Arial Bold");
gimp_image_merge_down($img, $text_layer, CLIP_TO_BOTTOM_LAYER); $text_layer = gimp_text_fontname($img,-1,0,0,"Testing testing", 0, 0, 14, 0, "Arial Bold");
gimp_image_merge_down($img, $text_layer, CLIP_TO_BOTTOM_LAYER); $text_layer = gimp_text_fontname($img,-1,0,0,"Testing testing", 0, 0, 14, 0, "Arial Bold");
gimp_image_merge_down($img, $text_layer, CLIP_TO_BOTTOM_LAYER); $text_layer = gimp_text_fontname($img,-1,0,0,"Testing testing", 0, 0, 14, 0, "Arial Bold");
gimp_image_merge_down($img, $text_layer, CLIP_TO_BOTTOM_LAYER); $text_layer = gimp_text_fontname($img,-1,0,0,"Testing testing", 0, 0, 14, 0, "Arial Bold");
gimp_image_merge_down($img, $text_layer, CLIP_TO_BOTTOM_LAYER);

My actual perl scripts are now resulting in what appears to be a memory leak that sporadically but consistently and permanently increases the memory being used by the Gimp instance, and the above is the best way I've found to consistently result in reproducing the issue. Please let me know of any thoughts on how to better pinpoint the issue.

I am using Gimp 2.0.5 for GNU/Linux, Gimp Perl 2.0 and Pango 1.6.

This is not surprising at all and it is not a memory leak. The memory that GIMP allocates for pixel data is allocated in tiles. The amount of memory that we allocate for a single tile is typically 16kB. This is a relatively small memory block which is handled in glibc using a memory pool. Thus, whenever GIMP allocates a new tile, this memory is served out of a memory pool held by glibc for the gimp application. If gimp frees this memory, it is marked as free in the glibc memory pool but it isn't returned to the OS. Thus any memory that gimp allocates for pixel data stays allocated for gimp even after gimp has released it already.

We have changed this behaviour in GIMP 2.1 by using the mallopt() call to tune the glibc memory handling.

Sven