From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27763 invoked by alias); 10 Dec 2001 19:44:45 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 26381 invoked from network); 10 Dec 2001 19:43:28 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 10 Dec 2001 19:43:28 -0000 Received: from drow by nevyn.them.org with local (Exim 3.33 #1 (Debian)) id 16DWKp-00026y-00; Mon, 10 Dec 2001 14:43:31 -0500 Date: Mon, 10 Dec 2001 11:44:00 -0000 From: Daniel Jacobowitz To: fnf@redhat.com Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: Patch for SIGSEGV in evaluate_subexp_standard Message-ID: <20011210144331.A7991@nevyn.them.org> Mail-Followup-To: fnf@redhat.com, gdb-patches@sources.redhat.com References: <200112101744.fBAHiMe20084@fishpond.ninemoons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200112101744.fBAHiMe20084@fishpond.ninemoons.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2001-12/txt/msg00276.txt.bz2 On Mon, Dec 10, 2001 at 10:44:21AM -0700, Fred Fish wrote: > This example demonstrates a bug that is triggered when a C++ file is > not compiled with -g. Attached is a proposed patch to fix the > problem. I've regression tested the patch with the gdb testsuite and > there are no regressions on an i686-pc-linux-gnu host. > > ========================= Begin example ========================= > (gdb) ptype x2.asString() > > Program received signal SIGSEGV, Segmentation fault. > 0x08079937 in evaluate_subexp_standard (expect_type=0x0, exp=0x860d330, pos=0xbfffed04, noside=EVAL_AVOID_SIDE_EFFECTS) at /src/sourceware/gdb/src/gdb/eval.c:929 > 929 struct type *ftype = > (top-gdb) list > 924 a function call. This is here because people often want to > 925 call, eg, strcmp, which gdb doesn't know is a function. If > 926 gdb isn't asked for it's opinion (ie. through "whatis"), > 927 it won't offer it. */ > 928 > 929 struct type *ftype = > 930 TYPE_TARGET_TYPE (VALUE_TYPE (argvec[0])); > 931 > 932 if (ftype) > 933 return allocate_value (TYPE_TARGET_TYPE (VALUE_TYPE (argvec[0]))); > (top-gdb) p argvec[0] > $1 = (struct value *) 0x0 > (top-gdb) bt > Here is the patch that fixes the bug. > > 2001-12-10 Fred Fish > > * values.c (value_fn_field): Add physname variable. Use a minimal > symbol if we don't find a full symbol. Remove setting of the new > value's type since that was already done by allocate_value(). > Remove obsolete commented out error call. I think that the patch itself is fine (though I can not approve it). But could you either add a check for NULL at the call site, or perhaps better add an error() like the commented out one in value_fn_field, unless it is ever useful for value_fn_field to return NULL? -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer