Re: [RFA] Fix leaks in macro definitions.

[Philippe Waroquiers <philippe.waroquiers@skynet.be>]

On Tue, 2019-01-15 at 10:15 -0700, Tom Tromey wrote:
> > > > > > "Simon" == Simon Marchi <simon.marchi@polymtl.ca> writes:
> 
> Simon> Would you consider that a bug in the splay tree implementation?
> Simon> Should it use the new key and free the old one with the key
> Simon> deallocation function?
> 
> Yes, I would think so as well, given that we pass key- and
> value-deletion functions to splay_tree_new_with_allocator.
> 
> Tom

For sure, what splay-tree.h/.c is doing now is underspecified,
and is not very clean/orthogonal for value/key memory mgt.
However, fixing this implies to revisit all the users of the
splay tree.
If this library is only used by gcc and gdb, then probably
the change in libiberty can be coordinated so that gcc and
gdb code is changed in sync.

But if libiberty is used 'in the field' by various other code
basis, fixing the splay tree to internally release the keys
in the cases exposed in the gdb leak (and patch) will cause
(silent) heap corruptions (double free) in all the splay tree
users that are today properly freeing the keys.
Not really a nice backward compatible fix :).

Deciding for a fix in splay tree for sure implies
more discussions (no idea who knows where libiberty is used).

Thanks

Philippe