From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-36824-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 7177 invoked by alias); 6 Feb 2010 16:26:00 -0000
Received: (qmail 7167 invoked by uid 22791); 6 Feb 2010 16:25:59 -0000
X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 	tests=AWL,BAYES_00,SPF_PASS
X-Spam-Check-By: sourceware.org
Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 06 Feb 2010 16:25:54 +0000
Received: (qmail 11016 invoked from network); 6 Feb 2010 16:25:53 -0000
Received: from unknown (HELO orlando) (pedro@127.0.0.2)   by mail.codesourcery.com with ESMTPA; 6 Feb 2010 16:25:53 -0000
From: Pedro Alves <pedro@codesourcery.com>
To: gdb@sourceware.org,  tromey@redhat.com
Subject: Re: [gdb-7.1] 10 days to branching...
Date: Sat, 06 Feb 2010 16:26:00 -0000
User-Agent: KMail/1.9.10
Cc: Kai Tietz <ktietz70@googlemail.com>,  Chris Sutcliffe <ir0nh34d@gmail.com>
References: <20100201081928.GA9204@adacore.com> <20100203193934.GA12020@ednor.casa.cgf.cx> <m33a1fcpe9.fsf@fleche.redhat.com>
In-Reply-To: <m33a1fcpe9.fsf@fleche.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain;   charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <201002061626.06963.pedro@codesourcery.com>
X-IsSubscribed: yes
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2010-02/txt/msg00042.txt.bz2

On Friday 05 February 2010 22:02:22, Tom Tromey wrote:
> >>>>> "cgf" == Christopher Faylor <cgf-use-the-mailinglist-please@sourceware.org> writes:
> 
> cgf> Any possibility that you can confirm whether this is a windows-only
> cgf> problem?
> 
> cgf> I think the only way to do that is to provide a test case.
> 
> It is not Windows-specific.  I reproduced it with a c++ program on my
> x86 F11 box.
> 
> The program comes from PR 9032:
> 
>     #include <stdio.h>
>     class InstSelection {
>     public:
>       InstSelection(double d) {
>       }
>     public:
>       virtual ~InstSelection(void);
>       void dump(void);
>     };
> 
>     InstSelection::~InstSelection(void)
>     {
>     }
> 
>     void InstSelection::dump(void)
>     {
>       printf("InstSelection::dump here\n");
>     }
> 
>     int main(void)
>     {
>       InstSelection *is = new InstSelection(17.0);
>       is->dump();
>       delete is; is = 0;
>       return 0;
>     }
> 
> I compiled it with the system g++, then ran CVS head gdb on the
> executable.  Finally:
> 
> (gdb) b InstSelection::InstSelection
> ../../src/gdb/breakpoint.c:4962: internal-error: set_raw_breakpoint: Assertion `sal.pspace != NULL' failed.
> 
> 
> The sal causing the problem in set_raw_breakpoint:
> 
> (top-gdb) p sal
> $10 = {
>   pspace = 0x0, 
>   symtab = 0x0, 
>   section = 0x0, 
>   line = 0, 
>   pc = 0, 
>   end = 0, 
>   explicit_pc = 0, 
>   explicit_line = 0
> }
> 
> That seems odd.

This one's been described and diagnosed in
PR10966 <http://sourceware.org/bugzilla/show_bug.cgi?id=10966>

The expr-cumulative work fixes this, but I listed in the PR
two possible quick workarounds.

Has a small objc testcase been found yet?  It could
simply be something forgetting to set the sal's pspace
around decode_objc, but then I'm confused at how it only
triggers in some cases, and the objc tests in our
testsuite pass.  It could yet be another bug that
was masked out before the pspace assertion was added,
like the PR10966 bug.

-- 
Pedro Alves