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

[Iñaki Ucar]

El lun., 20 ago. 2018 a las 22:16, Jan van der Laan
(<rhelp at eoos.dds.nl>) escribió:
>
> 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

This is something that could be done on CRAN in those machines that
perform UBSAN checks. I suggested it here:

https://stat.ethz.ch/pipermail/r-devel/2018-August/076636.html

One thing you could do is to try to detect whether lvec is being
compiled with sanitizers and then set that flag. But probably it's not
worth it so much trouble.

Iñaki

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


-- 
Iñaki Ucar