[Rd] C++ debugging help needed

[Duncan Murdoch]

On 13-10-02 4:26 PM, Romain Francois wrote:
> Le 02/10/13 22:15, Duncan Murdoch a écrit :
>> 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?
>
> That makes it less likely though.
>
> You could also use an unnamed namespace to sort of scope your code in
> your translation unit. See
> http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=/com.ibm.xlcpp8a.doc/language/ref/unnamed_namespaces.htm

I think those are restricted to a single .cpp file.  rgl has about 50 
.cpp files with a corresponding number of header files.  I want most of 
that to be in one namespace.

Duncan Murdoch

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