From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31927 invoked by alias); 24 Feb 2012 16:05:33 -0000 Received: (qmail 31919 invoked by uid 22791); 24 Feb 2012 16:05:32 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD 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; Fri, 24 Feb 2012 16:05:19 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1OG5IHF024738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 24 Feb 2012 11:05:19 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q1OG5H5Z011351; Fri, 24 Feb 2012 11:05:18 -0500 Message-ID: <4F47B53D.8050003@redhat.com> Date: Fri, 24 Feb 2012 16:09:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: Aleksandar Ristovski CC: gdb-patches@sources.redhat.com Subject: Re: [patch] Assert when 'break' with no arguments References: <20120214185333.GB14803@adacore.com> <4F3AB4AE.2010504@qnx.com> <4F3AC7A9.3020805@qnx.com> <4F47AFA8.7070302@redhat.com> <4F47B2A8.3070202@qnx.com> In-Reply-To: <4F47B2A8.3070202@qnx.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 2012-02/txt/msg00581.txt.bz2 On 02/24/2012 03:54 PM, Aleksandar Ristovski wrote: > On 12-02-24 10:41 AM, Pedro Alves wrote: >> On 02/14/2012 08:44 PM, Aleksandar Ristovski wrote: >>> --- gdb/stack.c 7 Feb 2012 04:48:22 -0000 1.247 >>> +++ gdb/stack.c 14 Feb 2012 20:43:08 -0000 >>> @@ -909,6 +909,11 @@ set_last_displayed_sal (int valid, struc >>> last_displayed_addr = addr; >>> last_displayed_symtab = symtab; >>> last_displayed_line = line; >>> + if (valid&& pspace == NULL) >>> + { >>> + warning (_("Trying to set NULL pspace.")); >> >> Is there a case when this isn't a gdb bug? IOW, any reason this isn't a gdb_assert? >> This seems like a rather cryptic warning to show to a user. > > I believe it would be a bug. > > However, gdb_assert is rather destructive. The warning is to bring it to our attention, but continue so users can actually do debugging if this happens. > > My thinking was: if sal is invalidated the rest of the code should continue functioning thus providing more value to the user (albeit maybe somewhat confused user) than killing the session. > > Anyway that was my rationale. Trouble is that cryptic warnings usually end up unnoticed and unreported (users will just shrug at gdb's lameness). If we clear the last displayed sal before issuing an internal error, then we're more sure to catch the bug, and users can still say no to "Quit this debugging session? (y or n)" and continue debugging. WDYT? diff --git a/gdb/stack.c b/gdb/stack.c index 070d658..22b16a5 100644 --- a/gdb/stack.c +++ b/gdb/stack.c @@ -911,8 +911,9 @@ set_last_displayed_sal (int valid, struct program_space *pspace, last_displayed_line = line; if (valid && pspace == NULL) { - warning (_("Trying to set NULL pspace.")); clear_last_displayed_sal (); + internal_error (__FILE__, __LINE__, + _("Trying to set NULL pspace.")); } } -- Pedro Alves