[Rd] C++ debugging help needed

[Romain Francois]

Le 02/10/13 17:05, Duncan Murdoch a écrit :
> A quick addition:
>
> If I add
>
> #define Shape rglShape
>
> near the top of my Shape.hpp header file, the bug goes away.  But I
> can't believe that would be necessary.  These are in separate packages,
> don't they have separate namespaces in C++?  How can I avoid clashes
> with types declared in other packages in the future?
>
> Duncan Murdoch

That is weird indeed and should not happen. But I don't know much 
linkers ...

I'd advise to scope code in some rgl namespace. At the moment (reading 
the code on r-forge) it's all in the global namespace.

This might be more involved than the macro trick you used above but this 
will be safer. It would have been more problematic if other packages 
needed to compile code against rgl headers, but apparently that is not 
what happens (you don't have inst/include and I don't see 
R_RegisterCCallable either) ...

Romain

> On 02/10/2013 10:50 AM, Duncan Murdoch wrote:
>> I've had reports lately about segfaults in the rgl package.  I've only
>> been able to reproduce these on Linux.   I am not so familiar with C++
>> details, so I have a couple of questions way down below. But first some
>> background info.
>>
>>    One recipe to recreate the crash works with a new version 5.0-1 of the
>> mixOmics package:
>>
>>   > library(mixOmics)
>>   > example(pca)
>>
>> This crashes with messages like this:
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x00007ffff28aafd9 in __exchange_and_add (__mem=0x7f7fffff7f7ffff7,
>>       __val=<optimized out>) at /usr/include/c++/4.7/ext/atomicity.h:48
>> 48        { return __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); }
>>
>> The call stack ends with this:
>>
>> #0  0x00007ffff28aafd9 in __exchange_and_add (__mem=0x7f7fffff7f7ffff7,
>>       __val=<optimized out>) at /usr/include/c++/4.7/ext/atomicity.h:48
>> #1  __exchange_and_add_dispatch (__mem=0x7f7fffff7f7ffff7,
>>       __val=<optimized out>) at /usr/include/c++/4.7/ext/atomicity.h:81
>> #2  _M_dispose (__a=..., this=0x7f7fffff7f7fffe7)
>>       at /usr/include/c++/4.7/bits/basic_string.h:242
>> #3  ~basic_string (this=0x15f8770, __in_chrg=<optimized out>)
>>       at /usr/include/c++/4.7/bits/basic_string.h:536
>> #4  Shape::~Shape (this=0x15f8760, __in_chrg=<optimized out>) at
>> Shape.cpp:13
>> #5  0x00007ffff22df50b in ~Background (this=0x15f8760,
>>       __in_chrg=<optimized out>) at Background.hpp:15
>> #6  Background::~Background (this=0x15f8760, __in_chrg=<optimized out>)
>>       at Background.hpp:15
>>
>> 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.
>> 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?
>>
>> - If I really do have calls to the wrong destructor in there, how do I
>> avoid this?
>>
>> Duncan Murdoch

-- 
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30