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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
