On Wed, 27 Feb 2008, Bill Skaggs wrote:
> It isn't tile *allocation* that matters here, it is tile *locking*,
> and locking only happens in one place, tile_lock() in
> app/base/tile.c. It should be pretty straightforward for
> you to throw some debugging code in there.
> As I wrote before, though, tile locking happens *a lot*.
> Many internal operations lock tiles transiently, and also
> any time tile data is transferred to a plugin, the tile is
> locked during the process. You might consider experimenting
> with an image small enough to fit entirely within a single
> tile (i.e., less than 64x64), if you are going to play with this
> stuff without getting flooded.
My apologies for the delay; I've had to do quite a bit of travelling
As Bill suggested, I instrumented tile_lock(). The coffee stain plugin is
definitely leaking tiles, and plug_in_gauss_iir appears to be the culprit,
although I haven't dug any deeper. Running the coffee stain
plugin from the UI repeatably results in leaked tiles (the more stains,
the greater the leak; at least 5 always results in a leak). I haven't
been able to cause leaks from the UI by using only Gaussian blur, although
Liam has apparently observed this.
Unfortunately, I don't have the time (or Scheme experience) to dig
further. There doesn't appear to be a Bugzilla bug open for this; shall I
file one against the plugins component?
Thanks to everyone for the help tracking this down!
Gimp-developer mailing list