From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64618 invoked by alias); 15 Jan 2019 19:46:00 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 64583 invoked by uid 89); 15 Jan 2019 19:45:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mailsec107.isp.belgacom.be Received: from mailsec107.isp.belgacom.be (HELO mailsec107.isp.belgacom.be) (195.238.20.103) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 15 Jan 2019 19:45:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skynet.be; i=@skynet.be; q=dns/txt; s=securemail; t=1547581555; x=1579117555; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=hRJm9hlVg+L9OMkxmcmzdpl+bYcLoa1K1oh+ObjNhLw=; b=jASyWASl2dn0Gv0fL1zhL7t5ws/PTQIW8C3GYoeYjy+wURD0UO+a7UYg 6NLHPuR01vx1kJK1sbJR34byF79Axw==; Received: from 184.205-67-87.adsl-dyn.isp.belgacom.be (HELO md) ([87.67.205.184]) by relay.skynet.be with ESMTP/TLS/AES256-GCM-SHA384; 15 Jan 2019 20:45:45 +0100 Message-ID: <1547581545.1726.3.camel@skynet.be> Subject: Re: [RFA] Fix leaks in macro definitions. From: Philippe Waroquiers To: Tom Tromey , Simon Marchi Cc: gdb-patches@sourceware.org Date: Tue, 15 Jan 2019 19:46:00 -0000 In-Reply-To: <87h8e9on9h.fsf@tromey.com> References: <20190115055611.17967-1-philippe.waroquiers@skynet.be> <63b6768fbedbe46b7a46f0d29f7b178c@polymtl.ca> <87h8e9on9h.fsf@tromey.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg00355.txt.bz2 On Tue, 2019-01-15 at 10:15 -0700, Tom Tromey wrote: > > > > > > "Simon" == Simon Marchi 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