C++ debugging help needed

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

C++ debugging help needed

Duncan Murdoch-2
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ debugging help needed

Duncan Murdoch-2
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ debugging help needed

Romain François-2
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ debugging help needed

Martyn Plummer-3
In reply to this post by Duncan Murdoch-2
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
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ debugging help needed

Dirk Eddelbuettel

On 2 October 2013 at 15:45, Martyn Plummer wrote:
| 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

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

And as I wrote to Duncan off-list, igraph doesn't, even though it otherwise
uses an igraph namespace:

   /** Shape.h
    */
   
   #ifndef SHAPE_H
   #define SHAPE_H
   
   #include <string>
   #include "Color.h"
   #include "Ray.h"
   #include "Point.h"
   
   class Shape
   [....]  

So the clash is due to two packages simulatenously failing to make use of
namespaces.  

And at that point the linker appears to pick in search (link ?) order.

Dirk

--
Dirk Eddelbuettel | [hidden email] | http://dirk.eddelbuettel.com

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ debugging help needed

Duncan Murdoch-2
Thanks Dirk, Martyn and Romain.  I'm planning to do a temporary
workaround release with the Shape class renamed to rglShape, but over
the longer term I'll put everything that's supposed to be local inside
an rgl namespace.  First I need to learn how namespaces interact with
extern "C" declarations; pointers to any readable tutorials would be
appreciated.

Duncan Murdoch

On 02/10/2013 11:52 AM, Dirk Eddelbuettel wrote:

> On 2 October 2013 at 15:45, Martyn Plummer wrote:
> | 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
>
> Exactly.
>  
> | at the top of any source file that refers to rgl Shape. Likewise, the
> | igraph package should declare shape in the "igraph" namespace.
>
> And as I wrote to Duncan off-list, igraph doesn't, even though it otherwise
> uses an igraph namespace:
>
>     /** Shape.h
>      */
>    
>     #ifndef SHAPE_H
>     #define SHAPE_H
>    
>     #include <string>
>     #include "Color.h"
>     #include "Ray.h"
>     #include "Point.h"
>    
>     class Shape
>     [....]
>
> So the clash is due to two packages simulatenously failing to make use of
> namespaces.
>
> And at that point the linker appears to pick in search (link ?) order.
>
> Dirk
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ debugging help needed

Romain François-2
Duncan,

extern "C" just means that the function(s) below it have C calling
conventions, so that .Call, .External, ... can find them. Without this,
your function names would be c++ mangled to disambiguate different
overloads.

What is inside can use namespace without any issue. You'd have something
like:

extern "C" SEXP dot_call_function(){
     rgl::Whatever object(1, 2 ) ;
     object.do_something() ;
     return R_NilValue ;
}

IIRC, if you register your functions (see WRE #5.4), you don't need
those extern "C" because you directly give the function pointer so you
don't have to search for it with its name.

Romain

Le 02/10/13 19:45, Duncan Murdoch a écrit :

> Thanks Dirk, Martyn and Romain.  I'm planning to do a temporary
> workaround release with the Shape class renamed to rglShape, but over
> the longer term I'll put everything that's supposed to be local inside
> an rgl namespace.  First I need to learn how namespaces interact with
> extern "C" declarations; pointers to any readable tutorials would be
> appreciated.
>
> Duncan Murdoch
>
> On 02/10/2013 11:52 AM, Dirk Eddelbuettel wrote:
>> On 2 October 2013 at 15:45, Martyn Plummer wrote:
>> | 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
>>
>> Exactly.
>> | at the top of any source file that refers to rgl Shape. Likewise, the
>> | igraph package should declare shape in the "igraph" namespace.
>>
>> And as I wrote to Duncan off-list, igraph doesn't, even though it
>> otherwise
>> uses an igraph namespace:
>>
>>     /** Shape.h
>>      */
>>     #ifndef SHAPE_H
>>     #define SHAPE_H
>>     #include <string>
>>     #include "Color.h"
>>     #include "Ray.h"
>>     #include "Point.h"
>>     class Shape
>>     [....]
>>
>> So the clash is due to two packages simulatenously failing to make use of
>> namespaces.
>>
>> And at that point the linker appears to pick in search (link ?) order.
>>
>> Dirk

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ debugging help needed

Ross Boylan
In reply to this post by Duncan Murdoch-2
On Wed, Oct 02, 2013 at 11:05:19AM -0400, Duncan Murdoch wrote:
....
>> 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.

That warning looks suspicious.  Are your sure gdb is finding the right
source files, and that the object code has been built from them?

>> 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?
>>

I don't know, but I think it's possible to give fully qualified type
names to gdb to force it to use the right definition.  That's assuming
that both Shape's are in different namespaces.  If they aren't, that's
likely the problem.

>> - If I really do have calls to the wrong destructor in there, how do I
>> avoid this?

Are you invoking the destructor explicitly?  An object should know
it's type, which should result in the right call without much effort.

>>
>> Duncan Murdoch
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ debugging help needed

Duncan Murdoch-2
On 02/10/2013 4:01 PM, Ross Boylan wrote:

> On Wed, Oct 02, 2013 at 11:05:19AM -0400, Duncan Murdoch wrote:
> ....
> >> 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.
>
> That warning looks suspicious.  Are your sure gdb is finding the right
> source files, and that the object code has been built from them?

I'm pretty sure that's a warning about the fact that igraph also has a
file called Shape.cpp, and the Shape::~Shape destructor was in that
file, not in my Shape.cpp file.

>
> >> 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?
> >>
>
> I don't know, but I think it's possible to give fully qualified type
> names to gdb to force it to use the right definition.  That's assuming
> that both Shape's are in different namespaces.  If they aren't, that's
> likely the problem.

Apparently they aren't, even though they are in separately compiled and
linked packages.  I had been assuming that the fact that rgl knows
nothing about igraph meant I didn't need to worry about it. (igraph does
list rgl in its "Suggests" list.)  On platforms other than Linux, I
don't appear to need to worry about it, but Linux happily loads one,
then loads the other and links the call to the wrong .so rather than the
local one, without a peep of warning, just an eventual crash.

Supposing I finish my editing of the 100 or so source files and put all
of the rgl stuff in an "rgl" namespace, that still doesn't protect me
from what some other developer might do next week, creating their own
"rgl" namespace with a clashing name.   Why doesn't the linking step
resolve the calls, why does it leave it until load time?


>> - If I really do have calls to the wrong destructor in there, how do I
>> avoid this?

Are you invoking the destructor explicitly?  An object should know
it's type, which should result in the right call without much effort.


No, this is an implicit destructor call.  I'm deleting an object whose
class descends from Shape.

Duncan Murdoch

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ debugging help needed

Romain François-2
Le 02/10/13 22:15, Duncan Murdoch a écrit :

> On 02/10/2013 4:01 PM, Ross Boylan wrote:
>> On Wed, Oct 02, 2013 at 11:05:19AM -0400, Duncan Murdoch wrote:
>> ....
>> >> 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.
>>
>> That warning looks suspicious.  Are your sure gdb is finding the right
>> source files, and that the object code has been built from them?
>
> I'm pretty sure that's a warning about the fact that igraph also has a
> file called Shape.cpp, and the Shape::~Shape destructor was in that
> file, not in my Shape.cpp file.
>>
>> >> 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?
>> >>
>>
>> I don't know, but I think it's possible to give fully qualified type
>> names to gdb to force it to use the right definition.  That's assuming
>> that both Shape's are in different namespaces.  If they aren't, that's
>> likely the problem.
>
> Apparently they aren't, even though they are in separately compiled and
> linked packages.  I had been assuming that the fact that rgl knows
> nothing about igraph meant I didn't need to worry about it. (igraph does
> list rgl in its "Suggests" list.)  On platforms other than Linux, I
> don't appear to need to worry about it, but Linux happily loads one,
> then loads the other and links the call to the wrong .so rather than the
> local one, without a peep of warning, just an eventual crash.
>
> Supposing I finish my editing of the 100 or so source files and put all
> of the rgl stuff in an "rgl" namespace, that still doesn't protect me
> from what some other developer might do next week, creating their own
> "rgl" namespace with a clashing name.   Why doesn't the linking step
> resolve the calls, why does it leave it until load time?

That makes it less likely though.

You could also use an unnamed namespace to sort of scope your code in
your translation unit. See
http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=/com.ibm.xlcpp8a.doc/language/ref/unnamed_namespaces.htm

>>> - If I really do have calls to the wrong destructor in there, how do I
>>> avoid this?
>
> Are you invoking the destructor explicitly?  An object should know
> it's type, which should result in the right call without much effort.
>
>
> No, this is an implicit destructor call.  I'm deleting an object whose
> class descends from Shape.
>
> Duncan Murdoch


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ debugging help needed

Ross Boylan
In reply to this post by Duncan Murdoch-2
On Wed, 2013-10-02 at 16:15 -0400, Duncan Murdoch wrote:

> On 02/10/2013 4:01 PM, Ross Boylan wrote:
> > On Wed, Oct 02, 2013 at 11:05:19AM -0400, Duncan Murdoch wrote:
> > ....
> > >> 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.
> >
> > That warning looks suspicious.  Are your sure gdb is finding the right
> > source files, and that the object code has been built from them?
>
> I'm pretty sure that's a warning about the fact that igraph also has a
> file called Shape.cpp, and the Shape::~Shape destructor was in that
> file, not in my Shape.cpp file.

I guess the notion of the "right" source file is ambiguous in this
context.  Suppose you have projects A and B each defining a function f
in f.cpp.  Use A/f() to mean the binary function defined in project A,
found in source A/f.cpp.

The you have some code that means to invoke A/f() but gets B/f()
instead.  Probably gdb should associate this with B/f.cpp, but your
intent was A/f() and A/f.cpp.  If gdb happens to find A/f.cpp, and A was
build after B, that could provoke the warning shown.

> >
> > >> 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?
> > >>
> >
> > I don't know, but I think it's possible to give fully qualified type
> > names to gdb to force it to use the right definition.  That's assuming
> > that both Shape's are in different namespaces.  If they aren't, that's
> > likely the problem.
>
> Apparently they aren't, even though they are in separately compiled and
> linked packages.  I had been assuming that the fact that rgl knows
> nothing about igraph meant I didn't need to worry about it. (igraph does
> list rgl in its "Suggests" list.)  On platforms other than Linux, I
> don't appear to need to worry about it, but Linux happily loads one,
> then loads the other and links the call to the wrong .so rather than the
> local one, without a peep of warning, just an eventual crash.

While various OS's and tricks could provide work-arounds for clashing
function definitions (I actually had the impression the R dynamic
loading machinery might) those wouldn't necessary be right.  In
principle package A might use some functions defined in package B.  In
that case the need for namespaces would have become obvious.

>
> Supposing I finish my editing of the 100 or so source files and put all
> of the rgl stuff in an "rgl" namespace, that still doesn't protect me
> from what some other developer might do next week, creating their own
> "rgl" namespace with a clashing name.   Why doesn't the linking step
> resolve the calls, why does it leave it until load time?

I think there is a using namespace directive that might save typing,
putting everything into that namespace by default.  Maybe just the
headers need it.

With dynamic loading you don't know til load time if you've got a
problem.  As I said, the systemm can't simply wall if different
libraries, since they may want to call each other.

The usual solution for two developers picking the same name is to have
an outer level namespace associated with the developer/company/project,
with other namespaces nested inside.  This reduces the problem, though
obviously it can still exist higher up.

Ross

>
>
> >> - If I really do have calls to the wrong destructor in there, how do I
> >> avoid this?
>
> Are you invoking the destructor explicitly?  An object should know
> it's type, which should result in the right call without much effort.
>
>
> No, this is an implicit destructor call.  I'm deleting an object whose
> class descends from Shape.
>
> Duncan Murdoch
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ debugging help needed

Duncan Murdoch-2
In reply to this post by Romain François-2
On 13-10-02 4:26 PM, Romain Francois wrote:

> Le 02/10/13 22:15, Duncan Murdoch a écrit :
>> On 02/10/2013 4:01 PM, Ross Boylan wrote:
>>> On Wed, Oct 02, 2013 at 11:05:19AM -0400, Duncan Murdoch wrote:
>>> ....
>>>>> 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.
>>>
>>> That warning looks suspicious.  Are your sure gdb is finding the right
>>> source files, and that the object code has been built from them?
>>
>> I'm pretty sure that's a warning about the fact that igraph also has a
>> file called Shape.cpp, and the Shape::~Shape destructor was in that
>> file, not in my Shape.cpp file.
>>>
>>>>> 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?
>>>>>
>>>
>>> I don't know, but I think it's possible to give fully qualified type
>>> names to gdb to force it to use the right definition.  That's assuming
>>> that both Shape's are in different namespaces.  If they aren't, that's
>>> likely the problem.
>>
>> Apparently they aren't, even though they are in separately compiled and
>> linked packages.  I had been assuming that the fact that rgl knows
>> nothing about igraph meant I didn't need to worry about it. (igraph does
>> list rgl in its "Suggests" list.)  On platforms other than Linux, I
>> don't appear to need to worry about it, but Linux happily loads one,
>> then loads the other and links the call to the wrong .so rather than the
>> local one, without a peep of warning, just an eventual crash.
>>
>> Supposing I finish my editing of the 100 or so source files and put all
>> of the rgl stuff in an "rgl" namespace, that still doesn't protect me
>> from what some other developer might do next week, creating their own
>> "rgl" namespace with a clashing name.   Why doesn't the linking step
>> resolve the calls, why does it leave it until load time?
>
> That makes it less likely though.
>
> You could also use an unnamed namespace to sort of scope your code in
> your translation unit. See
> http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=/com.ibm.xlcpp8a.doc/language/ref/unnamed_namespaces.htm

I think those are restricted to a single .cpp file.  rgl has about 50
.cpp files with a corresponding number of header files.  I want most of
that to be in one namespace.

Duncan Murdoch

>
>>>> - If I really do have calls to the wrong destructor in there, how do I
>>>> avoid this?
>>
>> Are you invoking the destructor explicitly?  An object should know
>> it's type, which should result in the right call without much effort.
>>
>>
>> No, this is an implicit destructor call.  I'm deleting an object whose
>> class descends from Shape.
>>
>> Duncan Murdoch
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ debugging help needed

Duncan Murdoch-2
In reply to this post by Ross Boylan
On 13-10-02 4:37 PM, Ross Boylan wrote:

> On Wed, 2013-10-02 at 16:15 -0400, Duncan Murdoch wrote:
>> On 02/10/2013 4:01 PM, Ross Boylan wrote:
>>> On Wed, Oct 02, 2013 at 11:05:19AM -0400, Duncan Murdoch wrote:
>>> ....
>>>>> 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.
>>>
>>> That warning looks suspicious.  Are your sure gdb is finding the right
>>> source files, and that the object code has been built from them?
>>
>> I'm pretty sure that's a warning about the fact that igraph also has a
>> file called Shape.cpp, and the Shape::~Shape destructor was in that
>> file, not in my Shape.cpp file.
>
> I guess the notion of the "right" source file is ambiguous in this
> context.  Suppose you have projects A and B each defining a function f
> in f.cpp.  Use A/f() to mean the binary function defined in project A,
> found in source A/f.cpp.
>
> The you have some code that means to invoke A/f() but gets B/f()
> instead.  Probably gdb should associate this with B/f.cpp, but your
> intent was A/f() and A/f.cpp.  If gdb happens to find A/f.cpp, and A was
> build after B, that could provoke the warning shown.
>
>>>
>>>>> 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?
>>>>>
>>>
>>> I don't know, but I think it's possible to give fully qualified type
>>> names to gdb to force it to use the right definition.  That's assuming
>>> that both Shape's are in different namespaces.  If they aren't, that's
>>> likely the problem.
>>
>> Apparently they aren't, even though they are in separately compiled and
>> linked packages.  I had been assuming that the fact that rgl knows
>> nothing about igraph meant I didn't need to worry about it. (igraph does
>> list rgl in its "Suggests" list.)  On platforms other than Linux, I
>> don't appear to need to worry about it, but Linux happily loads one,
>> then loads the other and links the call to the wrong .so rather than the
>> local one, without a peep of warning, just an eventual crash.
>
> While various OS's and tricks could provide work-arounds for clashing
> function definitions (I actually had the impression the R dynamic
> loading machinery might) those wouldn't necessary be right.  In
> principle package A might use some functions defined in package B.  In
> that case the need for namespaces would have become obvious.

The issue is that I don't need to import the problematic function from
another library.  It is not defined in the same .o file, but it is in
the same .dll/.so.   I think the linker should have resolved it, not
left it for later resolution by the loader.

I would expect to have problems if functions like Rprintf() were defined
in multiple places, because I need to import those.  But I think it's a
linker bug (or a bad design) in a case where the function is defined in
another .o file being linked into a shared library.

Duncan Murdoch

>
>>
>> Supposing I finish my editing of the 100 or so source files and put all
>> of the rgl stuff in an "rgl" namespace, that still doesn't protect me
>> from what some other developer might do next week, creating their own
>> "rgl" namespace with a clashing name.   Why doesn't the linking step
>> resolve the calls, why does it leave it until load time?
>
> I think there is a using namespace directive that might save typing,
> putting everything into that namespace by default.  Maybe just the
> headers need it.
>
> With dynamic loading you don't know til load time if you've got a
> problem.  As I said, the systemm can't simply wall if different
> libraries, since they may want to call each other.
>
> The usual solution for two developers picking the same name is to have
> an outer level namespace associated with the developer/company/project,
> with other namespaces nested inside.  This reduces the problem, though
> obviously it can still exist higher up.
>
> Ross
>>
>>
>>>> - If I really do have calls to the wrong destructor in there, how do I
>>>> avoid this?
>>
>> Are you invoking the destructor explicitly?  An object should know
>> it's type, which should result in the right call without much effort.
>>
>>
>> No, this is an implicit destructor call.  I'm deleting an object whose
>> class descends from Shape.
>>
>> Duncan Murdoch
>>
>>
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ debugging help needed

Duncan Murdoch-2
In reply to this post by Duncan Murdoch-2
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ debugging help needed

Martyn Plummer-3
Yes, on reflection it's an ABI problem on Linux (use of PIC code in
shared libraries means that any symbol can be interposed).  Using
namespaces isn't really the answer because that's an API issue.  I think
what you really need to do is control the visibility of your classes and
functions so that everything is hidden except for the entry points you
call from R (Writing R Extensions section 6.15).  This should stop the
symbol collision because hidden functions are resolved inside the shared
object instead of going through a lookup table that can be overwritten
by someone else's package.

Martyn



On Fri, 2013-10-04 at 15:05 -0400, Duncan Murdoch wrote:

> 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
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ debugging help needed

Duncan Murdoch-2
On 07/10/2013 12:18 PM, Martyn Plummer wrote:
> Yes, on reflection it's an ABI problem on Linux (use of PIC code in
> shared libraries means that any symbol can be interposed).  Using
> namespaces isn't really the answer because that's an API issue.  I think
> what you really need to do is control the visibility of your classes and
> functions so that everything is hidden except for the entry points you
> call from R (Writing R Extensions section 6.15).  This should stop the
> symbol collision because hidden functions are resolved inside the shared
> object instead of going through a lookup table that can be overwritten
> by someone else's package.

That's not possible on all platforms, but on platforms that allow it,
rgl (on R-forge) is now doing it.  It only exposes R_init_rgl(), which
registers all the other entry points.

I think the work that I did to add the namespace was also worthwhile for
those platforms that don't allow you to hide things; it makes collisions
less likely, though not impossible.

For those unfamiliar with this:  it is a little tedious to add external
registration, but you do gain extra checks on your calls. Once you have
that it is usually very easy to hide everything except the registration
function.  (One exception:  if your package has its own configuration
script, it's a bit more work.)

Duncan Murdoch

>
> Martyn
>
>
>
> On Fri, 2013-10-04 at 15:05 -0400, Duncan Murdoch wrote:
> > 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
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> -----------------------------------------------------------------------
> This message and its attachments are strictly confiden...{{dropped:8}}

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ debugging help needed

Dominick Samperi-3
In reply to this post by Martyn Plummer-3
I'm not sure if this is related, but there is one issue that needs to be
addressed a link time for object files that are generated from C++ code.
In C++ it is permissible to include definitions (not just declarations) in
header files. This means more that one object file may contain a definition
for the same function. The standard does not require linkers to check that
the definitions are consistent. The way this typically works (the tricks
vary by OS) is that the definitions are declared "weak," meaning they
do not lead to "multiple def" error messages. The linker simply deletes any
extra weak defs. Without this the common convention of placing both
defs and declarations in C++ header files (esp. when templates are
used) would not work.

Dominick



On Mon, Oct 7, 2013 at 12:18 PM, Martyn Plummer <[hidden email]> wrote:

> Yes, on reflection it's an ABI problem on Linux (use of PIC code in
> shared libraries means that any symbol can be interposed).  Using
> namespaces isn't really the answer because that's an API issue.  I think
> what you really need to do is control the visibility of your classes and
> functions so that everything is hidden except for the entry points you
> call from R (Writing R Extensions section 6.15).  This should stop the
> symbol collision because hidden functions are resolved inside the shared
> object instead of going through a lookup table that can be overwritten
> by someone else's package.
>
> Martyn
>
>
>
> On Fri, 2013-10-04 at 15:05 -0400, Duncan Murdoch wrote:
> > 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
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> -----------------------------------------------------------------------
> This message and its attachments are strictly confidenti...{{dropped:8}}
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel