From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16173 invoked by alias); 17 Nov 2005 09:46:00 -0000 Received: (qmail 16122 invoked by uid 22791); 17 Nov 2005 09:45:56 -0000 Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 17 Nov 2005 09:45:56 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id jAH9jC3f005777; Thu, 17 Nov 2005 10:45:12 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id jAH9jClG026329; Thu, 17 Nov 2005 10:45:12 +0100 (CET) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id jAH9jBle024772; Thu, 17 Nov 2005 10:45:11 +0100 (CET) Date: Thu, 17 Nov 2005 09:46:00 -0000 Message-Id: <200511170945.jAH9jBle024772@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: gdb@sourceware.org In-reply-to: <20051117041056.GC3513@nevyn.them.org> (message from Daniel Jacobowitz on Wed, 16 Nov 2005 23:10:56 -0500) Subject: Re: C++ related core dump References: <200511151015.jAFAFKXw032226@jop31.nfra.nl> <20051117041056.GC3513@nevyn.them.org> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00343.txt.bz2 > Date: Wed, 16 Nov 2005 23:10:56 -0500 > From: Daniel Jacobowitz > > On Tue, Nov 15, 2005 at 11:15:20AM +0100, Mark Kettenis wrote: > > I'm debugging some evil C++ code at work, and gdb keeps dumping core > > on me: > > > > (gdb) ptype antennac > > type = class ROScalarColumn : public virtual ROTableColumn { > > ... > > > Int operator()(unsigned int) const; > > > (gdb) p antennac(0) > > Segmentation fault (core dumped) > > > > This is with gcc 3.2 on sparc-sun-solaris2.7, which still uses stabs > > debugging info. > > > > I tracked it down to some code in valops.c:find_overload_match(), > > where SYMBOL_CPLUS_DEMANGLED_NAME is returning a null pointer which we > > pass to cp_func_name() and that function can't deal with that. As a > > stopgap, I applied the attached patch, and now I get: > > > > (gdb) p antennac(0) > > Invalid data type for function to be called. > > > > which isn't quite what I want, but at least keeps my gdb alive. > > > > What I really want of course is for the above to invoke > > antennac.operator()(0). Is that supposed to work at all? I know > > stabs support for C++ has issues, but reading the code I don't see how > > this would work for DWARF2 either. > > Well certainly that's not going to work :-) antennac(0) is not an > invocation of operator(). It's an invocation of the antennac class > constructor. If you want to invoke operator(), you need an object. > If you had an object, I would expect this to work (or mostly work); GDB > does support user-defined operators. No, no, you misread that bit above. antennac is an instance of class ROScalarColumn. So antennac(0) *is* an invocation of operator(). > GDB does _not_ support calling constructors, though. This is a bit > tricky. > > > Regardless of properly invoking operator(), we should do something > > about this crash. Can we do something better than the attached patch? > > > - func_name = cp_func_name (qualified_name); > > + if (qualified_name) > > + func_name = cp_func_name (qualified_name); > > Return earlier if fsym is not a function? Or this seems reasonable, to > avoid the crash. Hmm the comment just below mentions C-style functions. Doesn't SYMBOL_CPLUS_DEMANGLED_NAME (fsym) return NULL for C-style functions too? In that case I think my patch is indeed the right approach.