[Rd] C++ debugging help needed

[Duncan Murdoch]

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

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