[Rcpp-devel] Passing pointers to objects between libs results in weird UBSAN warning

Jan van der Laan rhelp at eoos.dds.nl
Mon Aug 20 16:18:10 CEST 2018



On 20-08-18 15:35, Iñaki Ucar wrote:
> El lun., 20 ago. 2018 a las 9:01, Jan van der Laan
> (<rhelp at eoos.dds.nl>) escribió:
>>

[SNIP]

>>       ========== pkg1/src/construct.cpp ================
>>       #include "../inst/include/pkg1.h"
>>
>>       // [[Rcpp::export]]
>>       RcppExport SEXP new_foobar(int i) {
>>         BEGIN_RCPP
>>         FooBar<int>* x = new FooBar<int>(i);
>>         return Rcpp::XPtr<Foo>(x, true);
>>         END_RCPP
>>       }
> 
> Note that RcppExport SEXP should be just SEXP. BEGIN_RCPP and END_RCPP
> should be dropped too.

You are right. Thanks. Mixing up old and new code.

[SNIP]


> 
> pkg2 compiles a shared library using pkg1's headers, but it does not
> link against libpkg1.so (in general, this is not possible in R). So
> both libpkg2.so and libpkg1.so define two copies of the same types,
> Foo and FooBar. pkg2 allocates FooBar from libpkg1.so and then
> dynamically casts it as FooBar from libpkg2.so. This is why clang
> complains. It has to do with how RTTI comparisons are done across
> dynamic objects (see, e.g.,
> https://whatofhow.wordpress.com/2015/03/17/odr-rtti-dso/).

This is roughly what I suspected. However, if I understand that article 
correctly problems should only occur with clang (which I am using; 
didn't mention that) and not with g++. However, the problems also occur 
with g++ 
(https://www.stats.ox.ac.uk/pub/bdr/memtests/gcc-UBSAN/ldat/ldat-Ex.Rout).


> 
> I'd say that these errors can be safely ignored, because types are
> exactly the same. Anyway, shouldn't it be easier to export get_foobar
> in pkg1?

Don't know how easy it is to convince the CRAN members to ignore the 
warnings. Of course, in this simple case, it is easier to define 
get_foobar in pkg1, but in the general case, for performance reasons, I 
would like to be able to access FooBar from other packages from c++ code.


Thanks for the response.

Jan







> 
> Iñaki
> 
>>
>> So, help!?
>>
>> Jan
>>
>>
>>
>>
>>
>> _______________________________________________
>> Rcpp-devel mailing list
>> Rcpp-devel at lists.r-forge.r-project.org
>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
> 
> 
> 


More information about the Rcpp-devel mailing list