On Fri, Jan 18, 2019 at 10:27 PM Tom Tromey <t...@tromey.com> wrote: > > Philippe Waroquiers noticed a memory leak in gdb, which he tracked > down to a bug in splay-tree. splay_tree_remove does not call the > `delete_key' function when it removes the old node; but it should. > > I looked at every splay tree in GCC and there is only one that passes > a non-NULL delete function -- the one in lto.c. That file does not > call splay_tree_remove. So, I think this is safe to check in. > > I re-ran the LTO tests to double check.
OK > libiberty/ > * splay-tree.c (splay_tree_remove): Delete the key if necessary. > --- > libiberty/ChangeLog | 4 ++++ > libiberty/splay-tree.c | 2 ++ > 2 files changed, 6 insertions(+) > > diff --git a/libiberty/ChangeLog b/libiberty/ChangeLog > index bcc0227bdd8..1eb25f928f2 100644 > --- a/libiberty/ChangeLog > +++ b/libiberty/ChangeLog > @@ -1,3 +1,7 @@ > +2019-01-18 Tom Tromey <t...@tromey.com> > + > + * splay-tree.c (splay_tree_remove): Delete the key if necessary. > + > 2019-01-14 Tom Honermann <t...@honermann.net> > > * cp-demangle.c (cplus_demangle_builtin_types) > diff --git a/libiberty/splay-tree.c b/libiberty/splay-tree.c > index 920e68db2cb..21d23c38dfc 100644 > --- a/libiberty/splay-tree.c > +++ b/libiberty/splay-tree.c > @@ -425,6 +425,8 @@ splay_tree_remove (splay_tree sp, splay_tree_key key) > right = sp->root->right; > > /* Delete the root node itself. */ > + if (sp->delete_key) > + (*sp->delete_key) (sp->root->key); > if (sp->delete_value) > (*sp->delete_value) (sp->root->value); > (*sp->deallocate) (sp->root, sp->allocate_data); > -- > 2.17.2 >
