From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72131 invoked by alias); 6 May 2019 21:40:59 -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 72121 invoked by uid 89); 6 May 2019 21:40:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=assurance, Therefore, sk:can_be_, held X-HELO: gateway32.websitewelcome.com Received: from gateway32.websitewelcome.com (HELO gateway32.websitewelcome.com) (192.185.145.123) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 06 May 2019 21:40:57 +0000 Received: from cm17.websitewelcome.com (cm17.websitewelcome.com [100.42.49.20]) by gateway32.websitewelcome.com (Postfix) with ESMTP id 71D6D308C224 for ; Mon, 6 May 2019 16:40:56 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id NlM0h6mAL90onNlM0hE6X5; Mon, 06 May 2019 16:40:56 -0500 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=ML4VQsYxrWA920xElj5LW61cbQ+/rI1ytCmxES5SQdY=; b=gWlD3UUy2+/XxdhZkptDQymjEU YnOkPgrC29lO8xJeAILoilvHRiS/itFyK9QanCjmWdEI5R4lNA1NVmEwabtXcCVKEIstfSb7OTtxj 9xthDL44bINyHB1Pzlj+hEij7; Received: from 97-122-168-123.hlrn.qwest.net ([97.122.168.123]:45388 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1hNlM0-003ijc-8J; Mon, 06 May 2019 16:40:56 -0500 From: Tom Tromey To: Jan Vrany Cc: Tom Tromey , gdb-patches Subject: Re: [RFC 8/8] mi/python: Allow redefinition of python MI commands References: <20190418152337.6376-1-jan.vrany@fit.cvut.cz> <20190418152337.6376-9-jan.vrany@fit.cvut.cz> <87h8al7tke.fsf@tromey.com> Date: Mon, 06 May 2019 21:40:00 -0000 In-Reply-To: (Jan Vrany's message of "Fri, 03 May 2019 16:26:45 +0100") Message-ID: <87woj3mfbs.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-05/txt/msg00178.txt.bz2 >>>>> "Jan" == Jan Vrany writes: Jan> Redefining python MI commands is especially useful when developing Jan> then. >> It seems like this could lead to difficulties with dangling pointers. >> Some assurance on this would be good. Jan> I'm not sure what exactly do you mean. However, I changed mi_command_py to Jan> use gdbpy_ref<> instead of PyObject* (or even void*). Jan> Therefore when one redefines the command: Jan> + if (mi_cmd_table.find (name) != mi_cmd_table.end ()) Jan> + if (! mi_cmd_table[name]->can_be_redefined ()) Jan> + return false; Jan> + Jan> + mi_cmd_table[name] = std::move (command); Jan> then the old command (if any) is destructed so Py_DECREF() is called on Jan> Python objech held on by mi_command_py() instance. Jan> I double checked by tracing it in GDB - I don't know how to write Jan> the test for for this though. Jan> Does above address your concern? The issue isn't a leak but rather the possibility of using an object after it's been destroyed. That is, if an MI command can be running when it is replaced, the code has to be sure that the command object isn't referenced after the replacement -- because the old object will have been destroyed. Tom