C++ related core dump

C++ related core dump

[Mark Kettenis]

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 {
  protected:
    Bool *canAccessColumn_p;
    Bool *reaskAccessColumn_p;

  public:
    ROScalarColumn();
    ROScalarColumn(Table const&, String const&);
    ROScalarColumn(ROTableColumn const&);
    ROScalarColumn(ROScalarColumn<int> const&);
    virtual ~ROScalarColumn();
    virtual class ROTableColumn * clone() const;
    void reference(ROScalarColumn<int> const&);
    void attach(Table const&, String const&);
    void get(unsigned int, int&) const;
    Int operator()(unsigned int) const;
    void getColumn(Vector<int>&, bool) const;
    Vector<int> getColumn() const;
    void getColumnRange(ArraySlicer const&, Vector<int>&, bool) const;
    Vector<int> getColumnRange(ArraySlicer const&) const;
    void getColumnCells(RefRows const&, Vector<int>&, bool) const;
    Vector<int> getColumnCells(RefRows const&) const;
  private:
    ROScalarColumn<int> & operator=(ROScalarColumn<int> const&);
    void reference(ROTableColumn const&);
    void checkDataType() 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.

Regardless of properly invoking operator(), we should do something
about this crash.  Can we do something better than the attached patch?

Mark

Index: valops.c
===================================================================
RCS file: /cvs/src/src/gdb/valops.c,v
retrieving revision 1.161
diff -u -p -r1.161 valops.c
--- valops.c	27 May 2005 04:39:32 -0000	1.161
+++ valops.c	15 Nov 2005 09:52:56 -0000
@@ -1847,7 +1847,8 @@ find_overload_match (struct type **arg_t
   else
     {
       const char *qualified_name = SYMBOL_CPLUS_DEMANGLED_NAME (fsym);
-      func_name	= cp_func_name (qualified_name);
+      if (qualified_name)
+	func_name = cp_func_name (qualified_name);
 
       /* If the name is NULL this must be a C-style function.
          Just return the same symbol. */

Re: C++ related core dump

[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<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.

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.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: C++ related core dump

[Mark Kettenis]

> 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.

Re: C++ related core dump

[Daniel Jacobowitz]

On Thu, Nov 17, 2005 at 10:45:11AM +0100, Mark Kettenis wrote:
> No, no, you misread that bit above.  antennac is an instance of class
> ROScalarColumn<int>.  So antennac(0) *is* an invocation of operator().

Oh.  Then what type IS the fsym?

> > 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.

Probably so, but let's work out what's going on first.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: C++ related core dump

[Mark Kettenis]

> Date: Thu, 17 Nov 2005 09:04:52 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Thu, Nov 17, 2005 at 10:45:11AM +0100, Mark Kettenis wrote:
> > No, no, you misread that bit above.  antennac is an instance of class
> > ROScalarColumn<int>.  So antennac(0) *is* an invocation of operator().
> 
> Oh.  Then what type IS the fsym?

Sorry, had a few days off at work.  Does this tell you enough?

p *fsym.type.main_type
$5 = {code = TYPE_CODE_STRUCT, upper_bound_type = BOUND_SIMPLE, 
  lower_bound_type = BOUND_SIMPLE, name = 0x0, 
  tag_name = 0x347f230 "ROScalarColumn<int>", objfile = 0x313260, 
  target_type = 0x0, flags = 4, nfields = 0, vptr_fieldno = -1, fields = 0x0, 
  vptr_basetype = 0x0, type_specific = {cplus_stuff = 0x2c3358, 
    floatformat = 0x2c3358}}

Mark

Re: C++ related core dump

[Daniel Jacobowitz]

On Tue, Nov 22, 2005 at 10:20:31AM +0100, Mark Kettenis wrote:
> > Date: Thu, 17 Nov 2005 09:04:52 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > 
> > On Thu, Nov 17, 2005 at 10:45:11AM +0100, Mark Kettenis wrote:
> > > No, no, you misread that bit above.  antennac is an instance of class
> > > ROScalarColumn<int>.  So antennac(0) *is* an invocation of operator().
> > 
> > Oh.  Then what type IS the fsym?
> 
> Sorry, had a few days off at work.  Does this tell you enough?
> 
> p *fsym.type.main_type
> $5 = {code = TYPE_CODE_STRUCT, upper_bound_type = BOUND_SIMPLE, 
>   lower_bound_type = BOUND_SIMPLE, name = 0x0, 
>   tag_name = 0x347f230 "ROScalarColumn<int>", objfile = 0x313260, 
>   target_type = 0x0, flags = 4, nfields = 0, vptr_fieldno = -1, fields = 0x0, 
>   vptr_basetype = 0x0, type_specific = {cplus_stuff = 0x2c3358, 
>     floatformat = 0x2c3358}}

That's what I thought; it's the type.  But how'd we get that?  It ought
to be the operator.  And, we shouldn't be using it at all; "method"
should have been set.  Looks to me like evaluate_subexp_standard is
broken for operator().

I apologize for my misleading comment earlier in the thread - we do
support user defined operators, but I don't see this particular one in
the testsuite.

-- 
Daniel Jacobowitz
CodeSourcery, LLC