Patch for PR 9399
Thu Dec 10 18:41:00 GMT 2009
Tom's approved this. That's fine. But for posterity:
On Wed, Dec 09, 2009 at 10:10:44AM -0500, Chris Moller wrote:
> >>You can see what the patch does by compiling -g virtfunc.cc, gdb-ing
> >>it, breaking in the return stmt at // marker1, and doing things like
> >>"print o.do_print()". Without the patch, gdb tries to access
> >>location 0x0; with the patch it does the right thing. (There are
> >>more tests in virtfunc2.exp)
> >Where does the access to 0x0 come from? Is it inside
> Ultimately, yes. Without the patch, the thread ultimately gets to
> if (BASETYPE_VIA_VIRTUAL (type, i))
> in search_struct_field and then to the memcpy about 30 lines later
> that extracts a new value struct. That main_type of that value
> doesn't include a field for the virtual function, so it's never
> found, and ultimately returns a null pointer. I haven't a clue why
> it works that way--for a while I was working on the assumption that
> the DWARF reader was screwing up, but if it is, it's too subtle for
I couldn't follow this and haven't had time to debug it myself yet.
But we shouldn't dereference any null (target) pointers in this. If
we do, there's a bug in some routine this function calls.
> > I wouldn't expect value_cast_structs to do any
> >cast in this case,
> value_cast_structs only does nothing if both TYPE_NAME()s are null.
> I was wondering if, back when the code was originally written, if
> there never was a case when both TYPE_NAME()s were non-null--it's the
> only way, other than simple oversight, I can account for that case
> not being covered.
No, it looks exactly like I intended. If we have two classes, we
check if A is a base class of B, then if B is a base class of A.
If A == B, neither of those checks will be true, and we'll return
without doing anything.
So the problem is that one of those base class checks is calling
error(). That's not supposed to happen.
More information about the Gdb-patches