Re: C++ related core dump

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Wed, 16 Nov 2005 23:10:56 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> 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<int> : 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<int>.  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.