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

[Kevin Ushey]

Perhaps I'm misunderstanding, but there is a Debian patch for RcppParallel here:

https://sources.debian.org/patches/r-cran-rcppparallel/5.0.2+dfsg-3/use_debian_packaged_libtbb.patch/

and all that does is force RcppParallel to use the Debian-provided
copy of TBB as opposed to the version normally bundled and installed
by RcppParallel itself.

Is the implied bug in the RcppParallel patch, or in RcppParallel itself?

Best,
Kevin

On Wed, Feb 10, 2021 at 10:18 AM Dirk Eddelbuettel <edd at debian.org> wrote:
>
>
> 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