Hi,

I'm developing a reasonably complex plugin for GIMP 2.4 in C++ (using GIMP and libgimp 2.4.2 on Ubuntu 7.10), and am currently having trouble with a Heisenbug: after running my plugin with a particular set of parameters, when I exit GIMP, I often (~90% of the time) get the following error:

Gimp-Base-WARNING **: tile ref count balance: 1858

aborting... gimp: terminated: Aborted

(where the number following 'balance' may vary). I've spent quite a while trying to track this down in my code without any luck -- random things seem to affect it, but valgrind doesn't report any rogue pointers, etc.

Is there any way to either trace the ref/deref of tiles, or at least get the tile ref balance via libgimp? I've dug around in the source, without finding much of use -- libgimp/gimptile.h includes ref and unref calls, but no way to check the current ref count. The warning is generated from app/base/tile-swap.c::tile_swap_exit() by calling tile_global_refcount(), but this is defined in app/base/tile.h, and does not appear to be exposed to plugins.

I'm at a bit of a loss, as I'm not doing *any* tile management on my own (e.g. no pixel region calls, nor any calls to ligimp/gimptile.h functions) -- the plugin is purely generative, making use of the various tools and a few standard plugins.

Any suggestions on how to go about debugging this would be greatly appreciated -- while this isn't actually stopping my plugin from working, it's hardly good form to make GIMP crash on exit. :-)

Thanks in advance,

Brennan

Basically this means that your plug-ins creates drawables and doesn't destroy them later nor does it attach them to any image. Of course it's not correct that GIMP allows plug-ins to do such things. It should clean up after them and release all resources they allocated. But this is not an ideal world and this cleanup mechanism in the core remains to be unimplemented. So as a plug-in developer you should be careful about releasing all resources you are allocating in the GIMP core.

Of course -- I wasn't expecting the GIMP to take out my trash for me, and I *thought* I had been careful to do so, but I'm clearly missing something. I've been going through old SVN versions of my plugin, and it looks like the bug has been there for a long time, but Gimp 2.2.11 doesn't report a tile ref error. Was there a change between 2.2 and 2.4 with respect to how various functions clean up, or is this likely just a change in reporting?

I'm mostly looking for ways to help me narrow this down -- I have ~5000 lines of potentially-suspect code, since I was developing under 2.2.11 until recently, and am having little luck. I've found various snippets that change the likelihood of the bug occurring (mostly involving invoking other plugins via gimp_run_procedure), but are insufficient to reproduce it when used in isolation. If there were a way to check the number of tiles currently allocated, I believe it would be useful in the triage process.

That said, I've sliced out chunks of my plug-in wholesale and run it with ltrace to catch all calls into the libgimp* family of libraries. Below is a (short) trace of an invocation that resulted in a tile ref count error. The likelihood of the problem occurring is ~proportional to the number of iterations of the denoted loop. Said loop is a one-for-one transcription of script_fu_coffee_stain (which calls a transcription of script_fu_distress_selection). I'll continue to eliminate code and try to create a self-contained example, but if anyone sees anything obviously wrong, I'd appreciate any pointers.

Thanks,

-Brennan

---------------------------------------------------------------------------

gimp_main(0x82a7880, 6, 0xbff0f494, 0x82511a9, 0xb7ef8800 gimp_procedural_db_get_data(0x8252d23, 0x82cdbe0, 0x8252d0b, 0x835f1f8, 0x8356dc8) = 0 gimp_procedural_db_get_data(0x8252d2c, 0x82d6c40, 0x8252d0b, 0x835f1f8, 0x8356dc8) = 0 gimp_procedural_db_get_data(0x8252d38, 0x82dfca0, 0x8252d0b, 0x835f1f8, 0x8356dc8) = 0 gimp_image_new(400, 410, 0, 0xb75e4ff4, 52) = 1 gimp_layer_new(1, 0x875b6f4, 400, 410, 1) = 2 gimp_image_add_layer(1, 2, -1, 410, 1) = 1 gimp_display_new(1, 2, -1, 410, 1) = 1 gimp_image_height(1, 0xbff0e0e4, 0xbff0e058, 0x820c437, 0xbff0e3b0) = 410 gimp_image_width(1, 0xbff0e0e4, 0xbff0e058, 0x820c437, 0xbff0e3b0) = 400

// Begin loop; below is repeated 20 times, with some randomized parameters // Start script_fu_coffee_stain transcription gimp_layer_new(1, 0x8269958, 400, 400, 1) = 3 gimp_image_add_layer(1, 3, 0, 400, 1) = 1 gimp_selection_all(1, 3, 0, 400, 1) = 1 gimp_edit_clear(3, 3, 0, 400, 1) = 1 gimp_ellipse_select(1, 0, 0x40666000, 0, 0x40666000) = 1 // Start script_fu_distress_selection transcription gimp_image_width(1, 0xb7da34b0, 0xbff0e038, 0xb73ac181, 0xb74c4070) = 400 gimp_image_height(1, 0xb7da34b0, 0xbff0e038, 0xb73ac181, 0xb74c4070) = 410 gimp_image_base_type(1, 0xb7da34b0, 0xbff0e038, 0xb73ac181, 0xb74c4070) = 0 gimp_layer_new(1, 0x82697f3, 400, 410, 1) = 4 // Scratch layer is removed from image below gimp_image_add_layer(1, 4, 0, 410, 1) = 1 gimp_selection_is_empty(1, 4, 0, 410, 1) = 0 gimp_edit_fill(4, 1, 0, 410, 1) = 1 gimp_selection_invert(1, 1, 0, 410, 1) = 1 gimp_selection_is_empty(1, 1, 0, 410, 1) = 0 gimp_edit_clear(4, 1, 0, 410, 1) = 1 gimp_selection_invert(1, 1, 0, 410, 1) = 1 gimp_selection_none(1, 1, 0, 410, 1) = 1 gimp_layer_scale(4, 100, 102, 1, 1) = 1 // plug_in_spread
gimp_run_procedure(0x826980a, 0xbff0e020, 0, 1, 13) = 0x8459e88 // plug_in_gauss_iir
gimp_run_procedure(0x8269819, 0xbff0e020, 0, 1, 13) = 0x87521b0 gimp_layer_scale(4, 400, 410, 1, 13) = 1 // plug_in_threshold_alpha
gimp_run_procedure(0x826982b, 0xbff0e020, 0, 1, 13) = 0x8459f48 // plug_in_gauss_iir
gimp_run_procedure(0x8269819, 0xbff0e020, 0, 1, 13) = 0x845a050 gimp_selection_layer_alpha(4, 0xbff0e020, 0, 1, 13) = 1 // Remove scratch layer
gimp_image_remove_layer(1, 4, 0, 1, 13) = 1 gimp_drawable_is_channel(3, 4, 0, 1, 13) = 0 // End script_fu_distress_selection transcription gimp_context_set_gradient(0x826995e, 1, 3, 0x4ba56359, 0x40369cb7) = 1 gimp_edit_blend(3, 3, 0, 8, 0) = 1 gimp_layer_set_offsets(3, 23, -17, 8, 0) = 1 // End script_fu_coffee_stain transcription // End loop

gimp_selection_none(1, 181, 188, 8, 0) = 1 gimp_procedural_db_set_data(0x8252d23, 0x82cdbe0, 36936, 0x82d6c2c, 0x82dfca0) = 1 gimp_procedural_db_set_data(0x8252d2c, 0x82d6c40, 36936, 0x82d6c2c, 0x82dfca0) = 1 gimp_procedural_db_set_data(0x8252d38, 0x82dfca0, 12288, 0x82d6c2c, 0x82dfca0) = 1 )
= 0
+++ exited (status 0) +++

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 lately.

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!

-Brennan