From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83414 invoked by alias); 15 Jan 2019 18:50:45 -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 83395 invoked by uid 89); 15 Jan 2019 18:50:44 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1214 X-HELO: gateway36.websitewelcome.com Received: from gateway36.websitewelcome.com (HELO gateway36.websitewelcome.com) (192.185.187.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 15 Jan 2019 18:50:42 +0000 Received: from cm16.websitewelcome.com (cm16.websitewelcome.com [100.42.49.19]) by gateway36.websitewelcome.com (Postfix) with ESMTP id 4FC24400C8776 for ; Tue, 15 Jan 2019 12:03:09 -0600 (CST) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id jTnNgNkFD4FKpjTnNgntu6; Tue, 15 Jan 2019 12:50:41 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=LbaG25ZE6S7ZstbYUGrKFxUKYiIzCha260gvR3JeeNQ=; b=c6V5LReo0M7nMrcvK2vTBP4MjJ Yqst3qmcJWFMFOibr52hODDOjM+YHqm7BMLEte4ylNUowvuZ02hpgY9vC26I2iLQOHMagJF/Mqrbc l6LaaqJueZbybliy5k4R3vu5f; Received: from 75-166-72-210.hlrn.qwest.net ([75.166.72.210]:36416 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gjTnN-000qJe-7m; Tue, 15 Jan 2019 12:50:41 -0600 From: Tom Tromey To: Simon Marchi Cc: Tom Tromey , Philippe Waroquiers , gdb-patches@sourceware.org Subject: Re: [RFA] Fix leaks in macro definitions. References: <20190115055611.17967-1-philippe.waroquiers@skynet.be> <63b6768fbedbe46b7a46f0d29f7b178c@polymtl.ca> <87h8e9on9h.fsf@tromey.com> <884d32995ce9ac8f412e22b5207d9a6d@polymtl.ca> Date: Tue, 15 Jan 2019 18:50:00 -0000 In-Reply-To: <884d32995ce9ac8f412e22b5207d9a6d@polymtl.ca> (Simon Marchi's message of "Tue, 15 Jan 2019 12:49:04 -0500") Message-ID: <87d0oxoiv3.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-01/txt/msg00353.txt.bz2 >>>>> "Simon" == Simon Marchi writes: Simon> Ok. Fixing this in the splay tree code would be a quite long task Simon> (reviewing all usages in binutils-gdb and gcc, I don't think this code Simon> is available externally?), so I am ok with this patch which fixes the Simon> issue in the mean time. Tom? Actually, I just misunderstood the patch and/or the splay-tree API. For some of the patch, the splay tree is doing the right thing. This applies to the macro_define_* patches. This though: @@ -841,8 +850,10 @@ macro_undef (struct macro_source_file *source, int line, arguments like '-DFOO -UFOO -DFOO=2'. */ if (source == key->start_file && line == key->start_line) - splay_tree_remove (source->table->definitions, n->key); - + { + splay_tree_remove (source->table->definitions, n->key); + macro_tree_delete_key (key); + } else { /* This function is the only place a macro's end-of-scope This one seems like it is definitely a splay-tree bug. The issue is that it deletes a node but not the node's key. I think it would be best by far to fix this in splay_tree_remove. I agree it's hard, but working around this seems worse to me. Tom