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@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel ----------------------------------------------------------------------- This message and its attachments are strictly confidenti...{{dropped:8}} ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel