[Rd] C++ debugging help needed

[Martyn Plummer]

In C++, everything goes in the global namespace unless the programmer
explicitly creates one. So when you dynamically load two dynamic shared
libraries with a "Shape" object they clash.

The solution here is to put 

namespace rgl {
...
}

around your class definitions in the rglm package, and 

using rgl::Shape

at the top of any source file that refers to rgl Shape. Likewise, the
igraph package should declare shape in the "igraph" namespace.

Martyn

On Wed, 2013-10-02 at 11:05 -0400, Duncan Murdoch wrote:
> 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
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-----------------------------------------------------------------------
This message and its attachments are strictly confidenti...{{dropped:8}}