From patchwork Sat Jan 19 17:29:23 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Philippe Waroquiers X-Patchwork-Id: 31130 Received: (qmail 13225 invoked by alias); 19 Jan 2019 17:29:39 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 13214 invoked by uid 89); 19 Jan 2019 17:29:37 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-27.6 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 spammy=children, Delete, HContent-Transfer-Encoding:8bit X-HELO: mailsec110.isp.belgacom.be Received: from mailsec110.isp.belgacom.be (HELO mailsec110.isp.belgacom.be) (195.238.20.106) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 19 Jan 2019 17:29:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skynet.be; i=@skynet.be; q=dns/txt; s=securemail; t=1547918975; x=1579454975; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=2RuNHAi8fmGc0RCrIx25RP1843x54wxUsZCoeP/jUCA=; b=WaEIrI7AvJhoj5HNJWv+o6ejuy+zYJu8Y7pzslLSpPfsT4ggcaeDEP/6 kFEvwN5ECPj9sesm9UeeciE8zNADQg==; Received: from 184.205-67-87.adsl-dyn.isp.belgacom.be (HELO md.ops.cfmu.eurocontrol.be) ([87.67.205.184]) by relay.skynet.be with ESMTP/TLS/DHE-RSA-AES128-GCM-SHA256; 19 Jan 2019 18:29:33 +0100 From: Philippe Waroquiers To: gdb-patches@sourceware.org Cc: Philippe Waroquiers Subject: [RFA] Fix leak detected in GDB test gdb.base/macscp.exp Date: Sat, 19 Jan 2019 18:29:23 +0100 Message-Id: <20190119172923.25343-1-philippe.waroquiers@skynet.be> MIME-Version: 1.0 X-IsSubscribed: yes When a node is removed from a splay tree, the splay tree was not using the function splay_tree_delete_key_fn to release the key. Fix the leak by calling the delete key function when removing a node. Also, clarify the documentation about when the release functions are called. include/ChangeLog 2019-01-19 Philippe Waroquiers * splay-tree.h (splay_tree_delete_key_fn): Update comment. libiberty/ChangeLog 2019-01-19 Philippe Waroquiers * splay-tree.c (splay_tree_remove): Call sp->delete_key. (splay_tree_new_typed_alloc): Update comment. --- include/splay-tree.h | 5 ++++- libiberty/splay-tree.c | 18 +++++++++++++++++- 2 files changed, 21 insertions(+), 2 deletions(-) diff --git a/include/splay-tree.h b/include/splay-tree.h index 0d26272943..44a9369d75 100644 --- a/include/splay-tree.h +++ b/include/splay-tree.h @@ -58,7 +58,10 @@ typedef struct splay_tree_node_s *splay_tree_node; typedef int (*splay_tree_compare_fn) (splay_tree_key, splay_tree_key); /* The type of a function used to deallocate any resources associated - with the key. */ + with the key. This is called to release the keys present in the + tree when calling splay_tree_delete or splay_tree_remove. The + caller of splay_tree_insert might have to call it if the same key + value is re-inserted in the tree. */ typedef void (*splay_tree_delete_key_fn) (splay_tree_key); /* The type of a function used to deallocate any resources associated diff --git a/libiberty/splay-tree.c b/libiberty/splay-tree.c index 920e68db2c..93069c5daa 100644 --- a/libiberty/splay-tree.c +++ b/libiberty/splay-tree.c @@ -318,7 +318,21 @@ different types need to be allocated with different allocators. The splay tree will use @var{compare_fn} to compare nodes, @var{delete_key_fn} to deallocate keys, and @var{delete_value_fn} to -deallocate values. +deallocate values. Keys and values will be deallocated when the +tree is deleted using splay_tree_delete or when a node is removed +using splay_tree_remove. splay_tree_insert will release the previous +value using @var{delete_value_fn} if the inserted key is already found +in the tree. In such a case, if the caller has allocated a new key +to call splay_tree_insert, it is the responsibility of the caller to +release the newly allocated key, as the tree does not take ownership +of the key given in argument in case of re-insertion of the same key +value. So, typically, the caller might do: + splay_tree_key k = ...allocate a key ...; + splay_tree_node s = splay_tree_insert (tree, k, value); + if ((struct macro_key *) s->key != k) + macro_tree_delete_key (k); +to ensure the newly allocated splay_tree_key k is released when the same +k value was already present in the tree. @end deftypefn @@ -427,6 +441,8 @@ splay_tree_remove (splay_tree sp, splay_tree_key key) /* Delete the root node itself. */ if (sp->delete_value) (*sp->delete_value) (sp->root->value); + if (sp->delete_key) + sp->delete_key (sp->root->key); (*sp->deallocate) (sp->root, sp->allocate_data); /* One of the children is now the root. Doesn't matter much