From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31343 invoked by alias); 26 Feb 2014 08:49:34 -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 31332 invoked by uid 89); 26 Feb 2014 08:49:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 26 Feb 2014 08:49:32 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1Q8nVvo014678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 26 Feb 2014 03:49:31 -0500 Received: from localhost.localdomain (ovpn-112-23.ams2.redhat.com [10.36.112.23]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1Q8nTxW003402 for ; Wed, 26 Feb 2014 03:49:30 -0500 Message-ID: <530DAA99.6090209@redhat.com> Date: Wed, 26 Feb 2014 08:49:00 -0000 From: Phil Muldoon MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: [patch][python] PR python/16324 (frame_id_eq check invalid) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-02/txt/msg00771.txt.bz2 This patch removes an invalid call to frame_id_eq. As the bug reporter noted, a frame_id_eq on two null_frame_ids will always return False (not True as expected in code). Add an assert over a Python error because this scenario is fatal (a null_frame_id should never be the result from a valid frame). A null_frame_id can be returned if the frame fetching function was passed a NULL (already checked earlier in the code), or if the frame is the SENTINEL (which it can't be, we are traversing the opposite way to encounter that). In the case of this check, GDB itself will have somehow corrupted the frame stack, in which case, the only thing to do is exit. I normally don't do this level of paranoia checking, but I wanted to respect the original author's intention. OK? Cheers, Phil -- 2014-02-26 Phil Muldoon PR python/16324 * python/py-finishbreakpoint.c (bpfinishpy_init): Assert on frame_id_p failing from a valid frame. Remove old frame_id_eq check. diff --git a/gdb/python/py-finishbreakpoint.c b/gdb/python/py-finishbreakpoint.c index 712a9ee..15952e3 100644 --- a/gdb/python/py-finishbreakpoint.c +++ b/gdb/python/py-finishbreakpoint.c @@ -207,9 +207,12 @@ bpfinishpy_init (PyObject *self, PyObject *args, PyObject *kwargs) else { frame_id = get_frame_id (prev_frame); - if (frame_id_eq (frame_id, null_frame_id)) - PyErr_SetString (PyExc_ValueError, - _("Invalid ID for the `frame' object.")); + + /* If prev_frame != NULL, and get_frame_id cannot return + the frame_id, there is nothing more to be done. At + this point, assert that a valid frame id is + returned. */ + gdb_assert (frame_id_p (frame_id) != 0); } } }