This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: C++ related core dump
> 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.