In my admittedly dogmatic opinion on this one subject, there are no excuses for physical leaks at least in any library that aims to be widely applicable. So I'd seek to bug the GTK+ developers until they fix it themselves.
It is trivial enough for a library to register
atexit callbacks to free any memory it allocates at least upon being unloaded. If it wants to avoid the expense of a boatload of teeny allocations, it shouldn't be doing them in the first place.
Even the laziest program that just wants to allocate a boatload of teeny chunks of memory at once could use a straightforward sequential allocator which just purges all memory at shutdown. If the allocator doesn't even want to deal with alignment, it can just pad every single chunk it pools to maximum alignment boundaries. If it was able to benefit with faster shutdown times by not freeing all those teeny chunks of memory individually, it likewise stands to benefit a great deal symmetrically in exchange for trivial effort by using such a sequential allocator which pools memory in a straight sequential fashion with much faster allocations than
malloc and more cache-friendly memory patterns, only to have all the big blocks of contiguous memory pooled by the allocator freed when when the library is done. All the library has to do then is replace their
malloc calls for which they don't bother to
free with something like
seq_malloc, and call
seq_purge in an
atexit callback to free all memory allocated upon being unloaded.
Otherwise you got this nasty library cluttering up messages in your memory leak detection tools you now have to filter out. Worse, if you don't systematically filter them out, they could obscure the leaks in your own application and your colleagues might develop the habit of overlooking them, reducing the usefulness of the leak detection tools in the first place in preventing your own team from pushing leaky code. It's gross and ugly and most of all I don't find the arguments in favor of doing this deliberately to be compelling at all given how trivial it is to use the solution above.
Logical leaks (the more complex kind that even garbage collection can't protect against) are a more complex issue, and there I could find some justification for short-lived programs to have logical leaks so long as they purge all that memory they allocated on shutdown since it requires a great deal of thought about resource management to avoid logical leaks (arguably more so in languages that have GC). But I don't find any reasonable excuse to avoid physical leaks given how trivial they are to avoid even in the laziest contexts.
Anyway, at the very least I'd filter out the leaks in valgrind so that they at least don't mess with your team's ability to spot your own.