>>I think you have hit an actual bug, and that it doesn't have anything
>>to do with python, because I have encountered a similar thing in a
>>modified version of gimpressionist that I worked up, written purely
>>in C.  I believe that there is some sort of memory leak that causes
>>gimp in some situations to maintain reference to tiles that are no
>>longer being used in any way, and it is something that shows up when
>>you create and delete layers over and over again, in a certain way.  
>>So it would probably be useful for you to file a bug report about this, 
>>if you would.
>It would only be useful if that bug report included a way to reproduce
>the problem. And it would probably be helpful to discuss that code
>example beforehand.
>I am not saying that there are no memory leaks in GIMP. But we are
>frequently testing the software for this and I am not aware of any major
>memory leaks such as the one that Bill describes here.
>>The memory that is being exhausted, by the way, is the "swap" area
>>that gimp allocates on the hard disk each time you run it.  The
>>tile manager moves tile data there if space is needed.
>Actually, it doesn't do that when space is needed, but when the memory
>allocated for tiles exceeds the limit configured as 'tile-cache-size'.

There could be a mix of a gimp bug, and definitely some portion of my 
plug-in. Although I know for a fact that I had a memory leak that was my 
fault, the reaction to the leak was unexpected. The system in question 
has only a /boot and /, with well in excess of 30 GB unused (lots of 
inodes as well). For a moment I thought that perhaps it was a max open 
file descriptor limit...which it could still be, but the system itself 
has a default setting of a max of around 76,618. The thing I did not 
expect was that it had well over a gig of ram left unused, no swap used, 
30 gig of unused drive, and it still thought the hard drive was full. On 
the other hand, it might not be worth pursuing when it requires a memory 
leak for it to show up.

I do believe that after using the delete function in the loop, that it 
still used up memory which it did not release. The amount was barely 
noticable though, and after running all night to create 45,000 800x800 
color jpegs, I'd say the amount was barely distinguishable as above the 
amount it started with (I didn't take exact measures, I was going by a 
mix of top and a graphical tool). Without a breakdown though of where 
gimp was using the memory, it'd be a bit of a stretch though to say it 
truly was a leak...it could simply be doing something like caching of 
something, e.g., it was using the text generation and changing fonts on 
each of the 45,000 images.

I know gimp has some ability to put out debug code, but I'm curious if 
it has any sort of way of dumping statistics on how it's using memory?

In the future I'll have to work on several plug-ins to do mass image 
handling, probably less than 45,000 per batch most of the time. I'll 
watch and see if I can find anything useful to report. Otherwise, just 
have a loop intentionally create 800x800 images without deleting, expect 
it to run out of resources, but see if it does it in the way 
expected...mine ran out of resources LONG before the system was even 
stressed slightly. Again, I suspect the slow laptop hard drive compared 
to fast core2 and tons of ram made it a race the hd could not win.

D. Stimits, stimits AT comcast DOT net
Gimp-developer mailing list

Reply via email to