Closed bbolker closed 12 hours ago
Hi, @bbolker. I'm not enough of a C guru to try to dig into this, but reading through your pain with lme4
, I think this is an outgrowth of whatever change was made to R's internal checking. BTW, you find these errors with the most recent, unpushed version of nloptr
, right?
I will run nloptr on r-devel before releasing next week and go back at you if I see these issues as well.
I just ran the master branch on rhub platform clang-asan R-devel (2024-06-14 r86747) Ubuntu 22.04.4 LTS
and there has been no issue.
However, it is not gcc-asan
.
To reproduce this:
docker pull rocker/r-devel-san
docker run --rm -ti rocker/r-devel-san bash
apt update && apt upgrade -y && apt install -y cmake
RD ## run development version of R
From inside R:
install.packages("remotes")
remotes::install_github("astamm/nloptr", force = TRUE)
library(nloptr)
fr <- function(x) { ## Rosenbrock Banana function
100 * (x[2] - x[1]^2)^2 + (1 - x[1])^2
}
(S <- bobyqa(c(0, 0, 0), fr, lower = c(0, 0, 0), upper = c(0.5, 0.5, 0.5)))
(Maintainer of that container here: It is imperative to use RD
as that is the SAN-instrumented version on the container and by standard debugging convention that is always the upcoming R version, ie r-devel, and therefore RD
. Standard 'r-release' aka R
is present to easily satisfy build and run-time dependencies. So in short: Do not expect effects to materialize on an uninstrumented version such as R
and use RD
to debug for SAN effects.)
It would be interesting to rebuild r-devel in this container with one or both of these lines commented out, to confirm that the enabling of these checks is indeed what drives the recent (??) appearance of these warnings.
PS I see the same errors with cobyla
, newuoa
, etc. (not lbfgs
or sbplx
), so it's fairly general.
Interesting, @bbolker. If I understand correctly, all three are algorithms by the late Dr. Michael Powell and all three work similarly. COBYLA constructs linear approximations and BOBYQA and its predecessor NEWUOA construct quadratic approximations. All three were originally Fortran code which was ported. So it stands to reason that the internals are similar. I haven't followed the discussion on R-devel too well (you and @eddelbuettel understand this much better), but there seems to be an issue passing a vector based on an empty? pointer, depending if it goes through the function REAL or the macro REAL, one of which uses DATAPTR and one does not. Lines 2082 and 2118, for example, are assignations to a vector. Are there possible cases where something isn't initialized properly and is empty? I am way out of my league 😞 .
@aadler we all are but Luke is working on that: https://mastodon.social/deck/@eddelbuettel/112633661372552025
Well, nlopt closed the issue as unreproducilble. @bbolker, are you still having this issue?
Probably too much trouble to try to reproduce it at this point -- go ahead and close.
I'm not sure why these aren't being flagged on CRAN yet, but when run with
r-devel
with address-sanitization flags on I get lots of errors ... haven't yet tried to see if this is new inr-devel
...