aboutsummaryrefslogtreecommitdiff
path: root/libiberty
diff options
context:
space:
mode:
authorTom Tromey <tom@tromey.com>2019-01-21 08:41:28 -0700
committerTom Tromey <tom@tromey.com>2019-01-21 09:05:01 -0700
commitd7167c671da0323daf31a8e07945c57c25f858d2 (patch)
treef51aa2a375d4c9bbeb38df4941b41a0579793682 /libiberty
parent73021deb50855f31bb312241899a464c62155f6a (diff)
downloadfsf-binutils-gdb-d7167c671da0323daf31a8e07945c57c25f858d2.zip
fsf-binutils-gdb-d7167c671da0323daf31a8e07945c57c25f858d2.tar.gz
fsf-binutils-gdb-d7167c671da0323daf31a8e07945c57c25f858d2.tar.bz2
Fix leak in splay-tree
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. libiberty/ * splay-tree.c (splay_tree_remove): Delete the key if necessary.
Diffstat (limited to 'libiberty')
-rw-r--r--libiberty/ChangeLog4
-rw-r--r--libiberty/splay-tree.c2
2 files changed, 6 insertions, 0 deletions
diff --git a/libiberty/ChangeLog b/libiberty/ChangeLog
index 436fb96..496d76d 100644
--- a/libiberty/ChangeLog
+++ b/libiberty/ChangeLog
@@ -1,3 +1,7 @@
+2019-01-21 Tom Tromey <tom@tromey.com>
+
+ * splay-tree.c (splay_tree_remove): Delete the key if necessary.
+
2019-01-01 Jakub Jelinek <jakub@redhat.com>
Update copyright years.
diff --git a/libiberty/splay-tree.c b/libiberty/splay-tree.c
index 920e68d..21d23c3 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);