Maximal number of DLLs reached

Interfaces RStan
1

Hi,

I recently upgraded my Ubuntu box to 20.04.
That entailed upgrading to R 4.0.2 and rstan 2.21.2.

After the upgrade, simulation code that had previously run fine started failing with this error:

Error in dyn.load(libLFile) : 
  unable to load shared object '/tmp/Rtmp551glh/file30a0cfc7f320.so':
  `maximal number of DLLs reached...
In addition: Warning message:
 Error in dyn.load(libLFile) : 
  unable to load shared object '/tmp/Rtmp551glh/file30a0cfc7f320.so':
  `maximal number of DLLs reached...

After some experimentation, I fixed the problem by re-writing my simulation loop to go something like:

library(rstan)
model <- stan_model(file = 'MyModel.stan')
for(i in 1:N) {
  df <- get_data()
  fit <- sampling(object = model, data = list(x=df$x, y = df$y))
  process_fit(fit)
}

rather than

library(rstan)
rstan_options(auto_write = TRUE)
for(i in 1:N) {
  df <- get_data()
  fit <- stan(file = 'MyModel.stan', data = list(x=df$x, y = df$y))
  process_fit(fit)
}

I.e. I think the repeated calls to stan(), which compiled and wrote the model on the first iteration, were causing the number of open DLLs to exceed some limit.
But that was avoidable by explicitly compiling the model once and then using sampling() rather than stan().
I probably should have written in this way in the first place.

Just posting this in case anyone else encounters the same error and this saves them some time.

[Going from memory, I think my previous setup was Ubuntu 18.04, R3.6.3, rstan 2.18.2]

Thanks,
Kristian

3 Likes
2

Yeah, using stan_model() and then sampling() is a safer option than stan() for something like this. That said, Iā€™m not exactly sure why this particular version of RStan forced you to make the change. Anyway, thanks for reporting this and sharing what ended up working.

1 Like
3

Yes