From murdoch.duncan at gmail.com  Wed Oct  2 22:15:56 2013
From: murdoch.duncan at gmail.com (Duncan Murdoch)
Date: Wed, 02 Oct 2013 16:15:56 -0400
Subject: [Rd] C++ debugging help needed
In-Reply-To: <20131002200118.GX32066@markov.biostat.ucsf.edu>
References: <524C32CF.2060307@gmail.com> <524C362F.1040108@gmail.com>
	<20131002200118.GX32066@markov.biostat.ucsf.edu>
Message-ID: <524C7EFC.5030605@gmail.com>

On 02/10/2013 4:01 PM, Ross Boylan wrote:
> On Wed, Oct 02, 2013 at 11:05:19AM -0400, Duncan Murdoch wrote:
> ....
> >> Up to entry #4 this all looks normal.  If I go into that stack frame, I
> >> see this:
> >>
> >>
> >> (gdb) up
> >> #4  Shape::~Shape (this=0x15f8760, __in_chrg=<optimized out>) at
> >> Shape.cpp:13
> >> warning: Source file is more recent than executable.
>
> That warning looks suspicious.  Are your sure gdb is finding the right
> source files, and that the object code has been built from them?

I'm pretty sure that's a warning about the fact that igraph also has a 
file called Shape.cpp, and the Shape::~Shape destructor was in that 
file, not in my Shape.cpp file.
>
> >> 13        blended(in_material.isTransparent())
> >> (gdb) p this
> >> $9 = (Shape * const) 0x15f8760
> >> (gdb) p *this
> >> $10 = {_vptr.Shape = 0x7ffff2d8e290, mName = 6, mType = {
> >>       static npos = <optimized out>,
> >>       _M_dataplus = {<std::allocator<char>> =
> >> {<__gnu_cxx::new_allocator<char>> =
> >> {<No data fields>}, <No data fields>},
> >>         _M_p = 0x7f7fffff7f7fffff <Address 0x7f7fffff7f7fffff out of
> >> bounds>}},
> >>     mShapeColor = {mRed = -1.4044474254567505e+306,
> >>       mGreen = -1.4044477603031902e+306, mBlue = 4.24399170841135e-314,
> >>       mTransparent = 0}, mSpecularReflectivity = 0.0078125,
> >>     mSpecularSize = 1065353216, mDiffuseReflectivity = 0.007812501848093234,
> >>     mAmbientReflectivity = 0}
> >>
> >> The things displayed in *this are all wrong.  Those field names come
> >> from the Shape object in the igraph package, not the Shape object in the
> >> rgl package.   The mixOmics package uses both.
> >>
> >> My questions:
> >>
> >> - Has my code somehow got mixed up with the igraph code, so I really do
> >> have a call out to igraph's Shape::~Shape instead of rgl's
> >> Shape::~Shape, or is this just bad info being given to me by gdb?
> >>
>
> I don't know, but I think it's possible to give fully qualified type
> names to gdb to force it to use the right definition.  That's assuming
> that both Shape's are in different namespaces.  If they aren't, that's
> likely the problem.

Apparently they aren't, even though they are in separately compiled and 
linked packages.  I had been assuming that the fact that rgl knows 
nothing about igraph meant I didn't need to worry about it. (igraph does 
list rgl in its "Suggests" list.)  On platforms other than Linux, I 
don't appear to need to worry about it, but Linux happily loads one, 
then loads the other and links the call to the wrong .so rather than the 
local one, without a peep of warning, just an eventual crash.

Supposing I finish my editing of the 100 or so source files and put all 
of the rgl stuff in an "rgl" namespace, that still doesn't protect me 
from what some other developer might do next week, creating their own 
"rgl" namespace with a clashing name.   Why doesn't the linking step 
resolve the calls, why does it leave it until load time?


>> - If I really do have calls to the wrong destructor in there, how do I
>> avoid this?

Are you invoking the destructor explicitly?  An object should know
it's type, which should result in the right call without much effort.


No, this is an implicit destructor call.  I'm deleting an object whose 
class descends from Shape.

Duncan Murdoch



[Rd] C++ debugging help needed
Duncan Murdoch