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

[Jan van der Laan]

On 20-08-18 17:59, Iñaki Ucar wrote:
> El lun., 20 ago. 2018 a las 16:18, Jan van der Laan
> (<rhelp at eoos.dds.nl>) escribió:
>>> 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 don't know, maybe things have changed in recent versions of gcc.
>
>>> 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.
> I've just submitted a PR to your repo that fixes the issue:
> https://github.com/djvanderlaan/lvec_ubsan/pull/1
>
> Copy&paste of the explanation there, for the interest of this list:
>
> Instead of using useDynLib in the NAMESPACE, this patch loads the
> library using library.dynam in .onLoad. In this way, we can take
> advantage of library.dynam's dots, which are mapped into the
> subsequent dyn.load call. This call has local=TRUE by default, i.e.,
> dlopen is called with the RTLD_LOCALattribute. Instead, local=FALSE
> sets RTLD_GLOBAL, which makes type_info from pkg1 available globally,
> and thus the RTTI error goes away.

OK, this seems to fix it. Not sure if the CRAN people like it when I 
register my symbols globally as this could bite other packages with the 
same symbol names. If I understand correctly; I am trying to read in on 
this stuff :-S

Tomorrow I will check with lvec and ldat.

Thanks.

Jan







>
> Iñaki
>
>>
>> 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
>>>
>>>
>
>