One of my packges gives a message with the undefined behaviour sanitiser
(UBSAN). I have difficulty tracking down/understanding the cause of this
message. However, I have been able to create a small example that
generates the same warning. The mail below is a bit on the long side,
and, I hop
El lun., 20 ago. 2018 a las 9:01, Jan van der Laan
() escribió:
>
>
> One of my packges gives a message with the undefined behaviour sanitiser
> (UBSAN). I have difficulty tracking down/understanding the cause of this
> message. However, I have been able to create a small example that
> generates t
On 20 August 2018 at 15:35, Iñaki Ucar wrote:
| El lun., 20 ago. 2018 a las 9:01, Jan van der Laan
| () escribió:
| >
| >
| > One of my packges gives a message with the undefined behaviour sanitiser
| > (UBSAN). I have difficulty tracking down/understanding the cause of this
| > message. However,
On 20-08-18 15:35, Iñaki Ucar wrote:
El lun., 20 ago. 2018 a las 9:01, Jan van der Laan
() escribió:
[SNIP]
== pkg1/src/construct.cpp
#include "../inst/include/pkg1.h"
// [[Rcpp::export]]
RcppExport SEXP new_foobar(int i) {
BEGIN_R
Hi Dirk,
The suggestion of Iñaki has been changed in the github code and also the
visitor stuff is not needed to trigger the exception.
On 20-08-18 16:01, Dirk Eddelbuettel wrote:
The only thought I had so far (and I had no time to play with the code) is to
maybe wrap Rcpp::Shield<> around
On 20 August 2018 at 16:26, Jan van der Laan wrote:
| Hi Dirk,
|
| The suggestion of Iñaki has been changed in the github code and also the
| visitor stuff is not needed to trigger the exception.
|
|
| On 20-08-18 16:01, Dirk Eddelbuettel wrote:
|
| >
| > The only thought I had so far (and
FWIW, there's an associated bug report here:
https://github.com/google/sanitizers/issues/911
that indicates that ubsan emits false positives when attempting to diagnose
functions opened through dlopen(), which IIUC is the standard way that R
loads symbols from compiled libraries in R packages
El lun., 20 ago. 2018 a las 16:18, Jan van der Laan
() 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 Foo
On 20-08-18 17:59, Iñaki Ucar wrote:
El lun., 20 ago. 2018 a las 16:18, Jan van der Laan
() 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
El lun., 20 ago. 2018 a las 22:16, Jan van der Laan
() escribió:
>
> On 20-08-18 17:59, Iñaki Ucar wrote:
> > El lun., 20 ago. 2018 a las 16:18, Jan van der Laan
> > () escribió:
> >>> pkg2 compiles a shared library using pkg1's headers, but it does not
> >>> link against libpkg1.so (in general, th
On 20 August 2018 at 22:16, Jan van der Laan wrote:
| > 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 h
11 matches
Mail list logo
