From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4730 invoked by alias); 24 Oct 2011 15:39:05 -0000 Received: (qmail 4716 invoked by uid 22791); 24 Oct 2011 15:39:03 -0000 X-SWARE-Spam-Status: No, hits=-7.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 24 Oct 2011 15:38:49 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p9OFcl1u030546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 Oct 2011 11:38:47 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p9OFclTp028000; Mon, 24 Oct 2011 11:38:47 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p9OFcjVp022469; Mon, 24 Oct 2011 11:38:45 -0400 From: Tom Tromey To: Paul Koning Cc: gdb-patches@sourceware.org, Phil Muldoon Subject: Re: [python] [patch] PR python/13331 References: <09787EF419216C41A903FD14EE5506DD030CE5E15C@AUSX7MCPC103.AMER.DELL.COM> <966B9848-BA1E-4777-BCE3-FD57AEA6E989@comcast.net> Date: Mon, 24 Oct 2011 15:47:00 -0000 In-Reply-To: <966B9848-BA1E-4777-BCE3-FD57AEA6E989@comcast.net> (Paul Koning's message of "Mon, 24 Oct 2011 11:31:07 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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 X-SW-Source: 2011-10/txt/msg00639.txt.bz2 >>>>> "Paul" == Paul Koning writes: Paul> In this loop there is an example of what I mentioned: if Paul> value_to_value_object returns NULL, exception status has been set, and Paul> that should not be overwritten here. On the other hand, there is Paul> missing cleanup: any objects added to the tuple before the failing Paul> call need to have a DECREF done on them. Won't decref'ing the tuple do this for us? If not then I think there are a lot of similar bugs elsewhere. But .. how could it not? That would be weird. Paul> That should just be a cleanup and return NULL -- the Paul> PyObject_GetAttrString has set the exception. This (fnpy_call) is a "gdb-facing" function, so it has to use error. It doesn't (and can't) follow the Python conventions. Tom