[R-pkg-team] Bug in r-base and r-cran-rcppparallel

[Dirk Eddelbuettel]

Hi Bastian,

Thanks for taking the time to propose a bug report.

However (and please see below) I don't think this is the way forward. There
have been a lot of recent changed in RcppParallel upstream (as I lurk on the
GH repo which is part of our Rcpp org), and maybe some of these things will
be different under the as-of-right-now-still-unreleased version 5.1.0 of
RcppParallel. I am CCing its (upstream) maintainer / core developer who is
also a friend and Rcpp collaborator. In the meantime please see
https://github.com/RcppCore/RcppParallel/blob/master/inst/NEWS

As for your suggested patch to R's own dynload.c:  that is very well tested
and robust system code I do not have any real intention of changing because
one package out of 17k at CRAN is having hickups under one (maybe suboptimal)
Debian config.

Maybe Andreas (for r-cran-rcppparallel) should talk to Kevin here to see what
if anything could or should be changed.

As for ~ expansion, we usually do that _before_ calling dyn.load() and
passing paths on to other C level functions:

   > Sys.glob("~/.Rprofile")
   [1] "/home/edd/.Rprofile"
   > 

I would be happy to take a patch forward to R Core and fend for it, as we
have in fact done in the past, but I think I would need to see a stronger
case of why we would all of a sudden inject a getcwd() here.  Happy to chat
more and hear real arguments if there are any.

Cheers,  Dirk

On 10 February 2021 at 18:55, Bastian Blank wrote:
| Control: clone -1 -2
| Control: reassign -1 r-base 4.0.3-1
| Control: retitle -1 r-base: dyn.load not useful for system libraries
| Control: affects -1 r-cran-rcppparallel 5.0.2+dfsg-3
| Control: severity -1 important
| Control: reassign -2 r-cran-rcppparallel 5.0.2+dfsg-3
| Control: retitle -2 r-cran-rcppparallel: generates broken load path for libtbb and fails on several architectures
| Control: severity -2 serious
| 
| Hi Andreas
| 
| This are actually two bugs:
| - r-base dyn.load not accepting relative library names on Linux systems
|   and
| - r-cran-rcppparallel trying to workaround the bug in dyn.load by
|   deducting the full path of libtbb from the architecture instead of the
|   correct multiarch setting and failing.
| 
| This has nothing to do with r-cran-rstan or r-cran-rstanarm, but it
| seems to be the first one to find out.  I've attached patches to fix
| both problems, properly re-assigned and adjusted the bugs.
| 
| This behaviour of R dyn.load might even be considered a security
| vulnerability, because loading libraries from the working directory is a
| problem.
| 
| Bastian
| 
| -- 
| Kirk to Enterprise -- beam down yeoman Rand and a six-pack.
| x[DELETED ATTACHMENT r-base_4.0.3-1.1.debdiff, plain text]
| x[DELETED ATTACHMENT r-cran-rcppparallel_5.0.2+dfsg-3.1.debdiff, plain text]

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org