thr3ads.net - R devel - [Rd] C++ debugging help needed [Oct 2013]

If this information is useful, please help other people find it:
Share via:

Duncan Murdoch

2013-Oct-02 14:50 UTC

[Rd] C++ debugging help needed

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

Duncan Murdoch

2013-Oct-02 15:05 UTC

head link

[Rd] C++ debugging help needed

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

Duncan Murdoch

2013-Oct-04 19:05 UTC

head link

[Rd] C++ debugging help needed

I have now got two "solutions" to this.  The rgl version currently on 
CRAN does a simple rename to avoid the name clash. A later version, 
still only on R-forge, puts most objects into a namespace called
"rgl".
(The old code had two small namespaces "gui" and "lib"; they
are gone now.)

I am not yet confident that the current version with namespaces will 
compile on all platforms; it seems much more fragile this way, with 
errors showing up on Linux that were not errors on Windows.  (E.g. 
sometimes I included a header with declarations in the rgl namespace 
followed by system header files, and the latter acted differently than 
they did when placed before the rgl header file, apparently declaring 
the system functions to be in a new anonymous namespace.)

rgl also includes some C code from the gl2ps project and some C++ code 
from FTGL; I didn't put those into the rgl namespace.  So there are 
still possibilities for clashes if anyone else uses those.

I'm still surprised that anything with plugins works on Unix-alike 
systems with such bizarre linking rules.  This is one of those few cases 
where the Windows design seems clearly superior.

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

Maybe Matching Threads

Search for more maybe matching threads

R devel - Oct 2013 - C++ debugging help needed

[Rd] C++ debugging help needed

[Rd] C++ debugging help needed

[Rd] C++ debugging help needed

Maybe Matching Threads