Andrei Simion wrote:

I run Gimp 2.2 on a Red Hat machine. The Perl scripts delete the images that are created by using gimp_image_delete. Even so, the swap file is created and it inflates significantly. For instance, after creating 250 images its size is of 2.7 MB. If the image is not deleted in the script, then after the same amount of images created the size of the swap file is of 900 MB.

I presume you meant 2.7 GB.

I ran into a similar thing some time ago, working with a modified version if gimpressionist that created and deleted lots of images. I think probably there is a bug somewhere responsible for it, but I never managed to figure it out. In any case, of course, Gimp 2.2 is no longer maintained and won't be fixed. You'll probably have to replicate this in Gimp 2.4 or 2.5 to get anybody interested.

-- Bill

Andrei Simion wrote:

I run Gimp 2.2 on a Red Hat machine. The Perl scripts delete the images that are created by using gimp_image_delete. Even so, the swap file is created and it inflates significantly. For instance, after creating 250 images its size is of 2.7 MB.

I have done some work on gimp-perl in recent months. A new version of gimp-perl is in the works. I still need to finish testing of the build and packaging of it.

I would be interested in a script that can demonstrate the problem. I have a client that uses gimp-perl with 2.2 and I'd like to alert them to the problem if it can be reproduced. I am even more interested to find out if the problem still exists with gimp-perl from SVN and a 2.4 version of GIMP.

Hi,

On Wed, 2008-03-26 at 22:11 -0400, Andrei Simion wrote:

I run Gimp 2.2 on a Red Hat machine. The Perl scripts delete the images that are created by using gimp_image_delete. Even so, the swap file is created and it inflates significantly. For instance, after creating 250 images its size is of 2.7 MB. If the image is not deleted in the script, then after the same amount of images created the size of the swap file is of 900 MB.

If I remember correctly, this is a known problem with at least some earlier GIMP versions. GIMP 2.2 is not any longer maintained, please try GIMP 2.4. If you should still see this problem there, then we would like to hear from you again, preferably with a test script that shows the problem.

Sven

Andrei Simion wrote:

If yes, I work for them and I saw that you modified some scripts there. We installed 2.2 version and I made sure the scripts properly generate the images we need.

I haven't met you. I was mainly dealing with Allan D., Chris C, and Trevor. I had let them know that 2.2 is considered unsupported suggested going straight to the 2.4 version of GIMP. I haven't heard anything for a while to know how things are going.

Hi,

On Thu, 2008-03-27 at 09:28 -0400, Andrei Simion wrote:

When I reported this issue on Gimp 1.2, you said it wasn't maintained any longer and to try version 2.2. I'll see if the upgrade can be done to version 2.4.

It took us years to get GIMP 2.4 out of the door. Obviously you guys are still always a little behind...

The bug might as well be in the gimp-perl bindings. But as long as you are not using the maintained stable version, there is not much we can do to help you.

Sven

Andrei Simion wrote:

We have installed the Gimp 2.4 and the swap file still grows. For instance after generating 20,000 images, the swap file size is 2.5 GB.

The script that is causing problems has 630 lines of code. Do you want me to copy-paste it here, in the body of the email?

Sending attachments to a list is not a good idea. I don't think this list allows it either.

You can post a pointer to a script that people can download and look at. Since you are talking about scripts that are used as part of your companies business, you may not want to make those scripts public.

As I worked on those scripts, I already have copies of them. If you remind me which of the three scripts (newimage, newimage5, or logov1) is the one used most, I can do some testing at my end. I will try to isolate the leak to a small set of operations or a specific API call.

I would be doing this on a volunteer basis as my free time permits (mainly weekends and possibly some evenings) in order to help see that a problem in gimp-perl, or GIMP, gets found and fixed.

-- 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 | -Pinkutus & the Borg

Andrei Simion wrote:

We have installed the Gimp 2.4 and the swap file still grows. For instance after generating 20,000 images, the swap file size is 2.5 GB.

If this is still happening in GIMP 2.4, a bug report should be opened against the gimp-perl component. It would also be a place to attach any script(s) which would allow someone to duplicate the problem.

Hi,

On Fri, 2008-03-28 at 14:20 -0400, Andrei Simion wrote:

The script that is causing problems has 630 lines of code.

It would help a lot if you could reduce the script to the most basic script that still shows the problem. Then we know better where to look for an error.

Sven

Hi,

On Wed, 2008-03-26 at 22:11 -0400, Andrei Simion wrote:

I run Gimp 2.2 on a Red Hat machine. The Perl scripts delete the images that are created by using gimp_image_delete. Even so, the swap file is created and it inflates significantly. For instance, after creating 250 images its size is of 2.7 MB.

That is not much and all it shows is that the image processing you are doing is using more memory than the configured tile-cache-size. I am not sure if I understand your problem at all...

I would be interested in eliminating the swap file or at least limiting its size. I think it should resize itself, but this doesn't happen.

The swap file only resizes itself when tiles at the end of the swap file are freed. So you may have to free all tiles before the swap file resizes itself to zero. If if doesn't do that, then your script leaks an image or a drawable somewhere (or it calls a function that leaks).

Sven

From: Sven Neumann
Date: Sat, 29 Mar 2008 18:24:59 +0100

On Wed, 2008-03-26 at 22:11 -0400, Andrei Simion wrote:

> I run Gimp 2.2 on a Red Hat machine. The Perl scripts delete the images > that are created by using gimp_image_delete. Even so, the swap file is > created and it inflates significantly. For instance, after creating 250 > images its size is of 2.7 MB.

That is not much and all it shows is that the image processing you are doing is using more memory than the configured tile-cache-size. I am not sure if I understand your problem at all...

> I would be interested in eliminating the swap file or at least limiting > its size. I think it should resize itself, but this doesn't happen.

The swap file only resizes itself when tiles at the end of the swap file are freed. So you may have to free all tiles before the swap file resizes itself to zero. If if doesn't do that, then your script leaks an image or a drawable somewhere (or it calls a function that leaks).

Perhaps a better test would be to create 250 images, destroy them, and repeat multiple times. If the swap file grows from iteration to iteration, that suggests a memory leak. As you point out, simply deleting some images won't necessarily allow the swap file to resize itself (unless GIMP actively compressed the swap file, which would be exceedingly time consuming).

A decent analogy here (and one also creates a lot of confusion) is the behavior of "free" over time. A lot of people get confused about why the amount of free memory reported by the OS decreases over time, and think that it represents a memory leak, when in fact that isn't the case.

On Sat, 29 Mar 2008 18:24:59 +0100, Sven Neumann wrote:

Hi,

On Wed, 2008-03-26 at 22:11 -0400, Andrei Simion wrote:

I run Gimp 2.2 on a Red Hat machine. The Perl scripts delete the images that are created by using gimp_image_delete. Even so, the swap file is created and it inflates significantly. For instance, after creating 250 images its size is of 2.7 MB.

That is not much and all it shows is that the image processing you are doing is using more memory than the configured tile-cache-size. I am not sure if I understand your problem at all...

I think as Bill pointed out that was a typo, it should have read 2.7GB, I believe that was confirmed.

I would be interested in eliminating the swap file or at least limiting its size. I think it should resize itself, but this doesn't happen.

The swap file only resizes itself when tiles at the end of the swap file are freed. So you may have to free all tiles before the swap file resizes itself to zero. If if doesn't do that, then your script leaks an image or a drawable somewhere (or it calls a function that leaks).

Sven

I agree there's not much point in having a complex script like 630 lines of proprietary code and reporting it as a GIMP bug. If there is an leakage issue here , that this rather extencive use is bringing to light, it certainly ought to be fixed but a simple test case that can be published is needed.

I think Kevin Cozens, who is familiar with the script, is looking at that.

/gg

Andrei Simion wrote:

We have installed the Gimp 2.4 and the swap file still grows. For instance after generating 20,000 images, the swap file size is 2.5 GB.

I will open a bug report so this issue won't get lost. What version of GIMP 2.4 did you install? You can find the full version number (ie. 2.4.5) in the "About GIMP" box (under the help menu in the Toolbox).

gg@catking.net wrote:

I agree there's not much point in having a complex script like 630 lines of proprietary code and reporting it as a GIMP bug. If there is an leakage issue here , that this rather extencive use is bringing to light, it certainly ought to be fixed but a simple test case that can be published is needed.

I plan to add a loop to invoke the script multiple times. When I am able to reproduce the problem I will look at converting the script to Script-Fu. By converting it to Script-Fu, which has had a lot of recent attention, it should help determine whether the problem is in GIMP or the gimp-perl binding.

Hi,

On Sat, 2008-03-29 at 15:34 -0400, Andrei Simion wrote:

I read that the tiles in the files should be empty in order to allow the swap to resize itself. But how I can do that? Is there a method that should be called after deleting the image?

Sorry, but you obviously do not understand what I am trying to explain. It probably doesn't make sense to continue this discussion further. Please show us a small script that allows us to reproduce the problem and we will check if there's a problem in the GIMP code that needs to be solved.

Sven

Kevin Cozens wrote:

I will open a bug report so this issue won't get lost.

Bug #525016 (http://bugzilla.gnome.org/show_bug.cgi?id=525016)

On Sat, 29 Mar 2008 23:26:34 +0100, Andrei Simion wrote:

If I show you a 20 lines script, then you'd have to generate the image maybe a million times to actually increase the swap. As Kevin said, there may be a leak in one of the method calls inside the script. And there are 104 calls.
Andrei

I think that's the point. It's your task to find out which (if any) of those 140 calls is causing a leak. If you can demonstrate a clearly defined reproducible problem it will get dealt with.

If the short script needs to run in a loop that can be arranged or the script can repeat the action if that is what is causing the problem.

It's also possible that in simplifying the script you will find an error you have overlooked.

In my experience, there's no better way to find a bug in your own software than to draft a detailed bug report about it being due to the other software you are using.

As Sven said , there is little point in continuing to discuss this until you can provide something clear and reproducible.

"I have 630 lines with 140 calls that has a bug but I cant show you" clearly will not get dealt with.

/gg

Seth Burgess wrote:

Way cool on someone doing gimp-perl work again! Sorry I've completely abandoned it, but I've got good reasons such as:

Congratulations on your latest "development project"! It is certainly of more importance than gimp-perl. The only downside being it is a long term project requiring approximately 18+ years of hands-on time. :-)