June 01-2001 Marc Lehmann wrote ("Re: [Gimp-developer] Perl Server Problem"):
On Fri, Jun 01, 2001 at 08:16:13PM +0200, Raphael Quinet <quinet@xxxxxxxxxx> wrote:
> Hey, this looks like a serious problem!
>
> recommend to use an old version such as 1.1.4, then they
> should definitely be fixed in 1.2.2, otherwise it is
> ridiculous to call this a "stable release"...It's simple: i had(!) a script which loaded and analyzed thousands of
(checked) jpegs and (unchecked) gifs. Broken gifs tend to hurt gimp badly,
with effects ranging from gimp filling all virtual memory to segfaulting
(and yes, sometimes cycling in the signal-catching code which, AFAIR, we
agreed to disable in 1.2).Deciding that gifs simply are broken anyway and gimp is easily fooled into
coring when fed illegal images I limited the script to jpegs (which have
been checked for correctness by re-writing them using jpegtran, which
never ever wrote a corrupt jpeg for me), which resulted in gimp eating
all available memory or hogging the cpu after 1000 images or so. I had to
limit the number of images processed to max. 200 per gimp process to limit
the effects a bit.I used the cvs snapshot from maybe three or four weeks ago (1.2 branch),
which was well after 1.2.1.
<snipped....>June 02 2001: Jesse Pavel wrote: ("Re: [Gimp-user] Swap File Usage")Used interactively, I don't have any problems with gimp-1.2, most probably
because I rarely load more than 10 images ;) Only when I use ti as a
batch-processing tool, which is difficult anyway ;)
Hi,Well, the general repetitive usage pattern:I'm running gimp 1.2.1 with a disk quota, and I'm hitting some swap file
size problems. I set the tile cache to 75MB, undo levels to 4, but when I
edit even smaller images (1600x1200 24bit), the gimp swap file grows in a
seemingly unbounded way, past 30MB in size and growing until I quit. Then,
when I quit the Gimp, I get a Gimp-warning that the swap file is not
empty, and then a large list of ranges. Has anyone encountered this
problem before, and found a fix? I can recompile the Gimp with different
flags if necessary.Thanks,
Jesse
open Gimp;
foreach 1..n i of "Gimp images"
{
open i;
// Do something with i;
close i;
}
close Gimp;
generally leads to extraordinarily large memory footprints
and, often on Gimp exit, dumps of swap files with
still-breathing tiles.
After spending a couple of days with #55686,
I'm convinced that
Gimp does not release the drawable components of GimpImages.
It cleans up the undo stacks fine, and the shadow, projection, and
selection masks are cleaned up, but the layers on GimpImage::layers
list never, ever have their GtkObject class destructors called.
[gimp_layer_destroy() layer.c-CVS-1.71.]. Go on. Hang a break
point there. Nada. Nothing. Nihil. After the once-associated
GimpImage itself is in bit-heaven, the orphaned layers hang
around in unreferenced-but-intact states until after the Gimp
itself exits. In the repetitive use case above, this happy state
of
affairs induces Gimp to leak tile managers into the cache (or swap)
Big Time, though in single image use cases, many would probably
not notice too much amiss (I didn't).
What bemuses me is this "sink-but-not-really-sink" policy for
layers and channels that prevails around 1.2.1 tile mismanagement,
and
which finds partial realization in layer_ref(). [layer.c-CVS-1.72.2.1
gimp-1-2]
This brief little snippet explicitly increments the object reference
count of layers (gtk_object_ref()) before invoking gtk_object_sink().
After this intrusion into private GTK object management has been
pulled off,
we are left with a special layer that is not floating, but not quite
sunk
either (it has a positive reference count). From this point forward,
invoking
gtk_object_sink() on this "special layer" has no effect whatsoever:
gtk_object_sink() thinks the object is sunk and leaves
its reference count alone. Also (and is this side-effect *wanted* ?)
GTK+
never invokes the layer class destructor on the object either (but
callbacks
registered on the layer "destroy" signal are invoked. These handlers
are
not intended to be object destructors; they are intended for other
objects to
do whatever they need to do when GTK announces a layer's destruction.
I am
referring to the object class destructor set up in gimp_layer_class_init(),
where
GtkObject::destroy is set to gimp_layer_destroy()).
The strange manipulations of layer_ref() is limited to gimp_image_add_layer(),
where it is applied on layers that are being addedto the list in GimpImage::layers
It is these layers alone that acquire a persistence that I think
is working rather
too well -- they never go away, and are leading to the memory leakage
that
others are observing. That they never go away is a point I am convinced;
see
the stack traces I got from watchpoints set on the low-level tile
manager creator
and destructor, attached to #55686.
Tile Mismanagement. Oops. Freudean slip there. But personally, I think
that anyone reaching around an object interface to muck with reference
counting is Asking For It, and -- guess what! -- we Got It: a Big Fat
Happy Gimp. The motivation for this layer_ref() trickery appears
to
date to Feb - August 1998 (Gimp 0.99.x) when Scott Goehring first
Objectified Gimp drawables. GTK was in flux then as well, and
I surmise
(reading mail from the period is not clear on this) that GTK object
referencing
was a bit queer anyway. If so, is layer_ref() (and its effects) a
kludge that
has outlived its usefulness? Quite frankly, I get better
memory management
when I disable this non-standard reference manipulation and leave
GTK object management internals undisturbed. destructors destroy
when
they are supposed to; memory use is high but seems to plateau. But
I
haven't assessed the side-effects and side-side effects of this. Some
weeks of testing is needed, I think.
Anyone active in Gimp Affairs around that time care to comment?
Personally, I think this is a must-fix that justifies a 1.2.2
release,
keen though I am to be working on 1.3/2.0 functionality.
TIA for your thoughts.
Be good, be well
Garry
