`rstan` API calls crash `R` in `RStudio` (reason for `bridgesampling` crashes)

Interfaces RStan
1

After having received a few reports of R crashes from bridgesampling users, I seem to have isolated the problem as calls to the rstan API on fitted model objects in RStudio.

In particular, the last two lines of the following code crash the R session reliably when run inside RStudio but not when run inside “bare” R. Seems to happen on both Windows and Mac and even after updating RStudio to the latest version or development version.

library("rstan")
stanmodelcode <- "
data {
  int<lower=0> N;
  real y[N];
} 

parameters {
  real mu;
} 

model {
  target += normal_lpdf(mu | 0, 10);
  target += normal_lpdf(y  | mu, 1);
} 
"

y <- rnorm(20) 
dat <- list(N = 20, y = y); 
fit <- stan(model_code = stanmodelcode, model_name = "example", 
            data = dat, chains = 0) 
unconstrain_pars(fit, list(mu = 0))
log_prob(fit, c(mu = 0))

Not sure there is much that can be done, but still wanted to let people know.

Also, it does not seem to crash on RStudio Server, although I haven’t tested it thoroughly.

2

Does using the stan-dev version of rstan help?

remove.packages(c("StanHeaders", "rstan"))
install.packages("StanHeaders", repos = c("https://mc-stan.org/r-packages/", getOption("repos")))
install.packages("rstan", repos = c("https://mc-stan.org/r-packages/", getOption("repos")))
3

Thanks, that does fix it (at least with RStudio development version, haven’t tested further). Any idea when this will go to CRAN?

4

That is very hard to predict. Maybe @andrjohns or @hsbadr would know more.

5

I’m a bit out of date on the CRAN progress sorry, will have to wait for Hamada

6

No problem. We will inform users that they have to use the development version until then.

7

It’s up to @bgoodri now. There’s one major issue on Windows that’s temporary and can be bypassed: rstan classes depend on the headers they used at compilation time and it should be rebuilt from source after updating StanHeaders. Since we plan to update rstan 2.26 immediately after releasing StanHeaders 2.26 (and reverse dependency checks are run on Linux), this is a temporary issue on Windows. So, we could start preparing for a quick release or delay everything until we make any changes required for rstan to be compatible with all versions of the headers at both compilation and runtime. I haven’t looked into it because I think it isn’t worth the time if we can bypass it or maybe coordinate with CRAN.

1 Like
8

Thanks for the update.