Exceeded maximum number of DLLs in RStan

[Doug Jackson]

Hi all,

I recently posted a question to stackoverflow (before I was aware of this Google Group) regarding a problem I'm having with RStan.
http://stackoverflow.com/questions/24832030/exceeded-maximum-number-of-dlls-in-r

The basic issue is that when I create a large number of Gaussian Process fits, I'm running up against the maximum number of DLLs allowed in R, as every new fit loads another DLL. The stackoverflow question includes the details, as well as some example code the reproduces the issue, so I won't repeat them here.

The output of my sessionInfo() in R is:

R version 3.1.0 (2014-04-10)
Platform: x86_64-apple-darwin13.1.0 (64-bit)

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base    

other attached packages:
[1] rstan_2.3.0   inline_0.3.13 Rcpp_0.11.2 

loaded via a namespace (and not attached):
[1] codetools_0.2-8 stats4_3.1.0   

Thanks,
Doug

[Jeffrey Arnold]

I answered your question on stackoverflow:
http://stackoverflow.com/a/24834763/227406. It doesn't directly
address the too many dll problem, but you shouldn't need to generate
100 dll's because you shouldn't need to compile the same model 100
times.

> --
> You received this message because you are subscribed to the Google Groups
> "Stan users mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to stan-users+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Andrew Gelman]

You can use the stan_run() function; just cut and paste this:

stan_run <- function(stanModel, ...) {
if(class(stanModel) == "stanfit") {
stanExe <- stanModel
} else {
stanModel.rda <- gsub("stan$", "rda", stanModel)
if(!file.exists(stanModel.rda) || file.info(stanModel.rda)$mtime < file.info(stanModel)$mtime) {
cat("Model",stanModel,"needs recompilation.\n")
args <- modifyList(list(...), list(file=stanModel, iter=0, warmup=0, chains=0))
stanExe <- do.call(stan, args)
saveRDS(stanExe, file=stanModel.rda)
} else {
cat("Loading cached stan model", stanModel, ".\n")
stanExe = readRDS(stanModel.rda)
}
}
# This bit with the seed is for debugging purposes; once we figure out why Stan is crashing R we can remove it.
seed <- sample.int(.Machine$integer.max, 1)
write (paste (stanModel, seed), file="stan_seed.txt")
stan(fit=stanExe, seed=seed, …)
}

An example of the use of this function is here:
http://andrewgelman.com/2014/07/13/stan-analyzes-world-cup-data/
Basically, you use it like you’d use stan() and it automatically only recompiles the model when needed.

We’re planning to have this behavior automatically in rstan3, but for now you can use stan_run()

[Doug Jackson]

Thanks Jeffrey and Andrew. These are exactly the types of answers I was hoping for. I had a sneaking suspicion that all the compiling I was doing was unnecessary, and my code does indeed run much, much faster now.

On Fri, Jul 18, 2014 at 3:43 PM, Andrew Gelman <gel...@stat.columbia.edu> wrote:

You can use the stan_run() function; just cut and paste this:

stan_run <- function(stanModel, ...) {
  if(class(stanModel) == "stanfit") {
    stanExe <- stanModel
  } else {
    stanModel.rda <- gsub("stan$", "rda", stanModel)
    if(!file.exists(stanModel.rda) || file.info(stanModel.rda)$mtime < file.info(stanModel)$mtime) {
      cat("Model",stanModel,"needs recompilation.\n")
      args <- modifyList(list(...), list(file=stanModel, iter=0, warmup=0, chains=0))
      stanExe <- do.call(stan, args)
      saveRDS(stanExe, file=stanModel.rda)
    } else {
      cat("Loading cached stan model", stanModel, ".\n")
      stanExe = readRDS(stanModel.rda)
    }
  }
  # This bit with the seed is for debugging purposes; once we figure out why Stan is crashing R we can remove it.
  seed <- sample.int(.Machine$integer.max, 1)
  write (paste (stanModel, seed), file="stan_seed.txt")

  stan(fit=stanExe, seed=seed, ...)

You received this message because you are subscribed to a topic in the Google Groups "Stan users mailing list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/stan-users/D3p1FTu3U1M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to stan-users+...@googlegroups.com.

[Bob Carpenter]

Andrew's been the only one using this function and the
only one reporting R crashing on him. I don't know if
there's a connection, but if others run this function and
R crashes, could you please let us know?

Thanks,

- Bob

[Andrew Gelman]

Hi, Bob. I hate to burst your bubble but Stan has crashed my R when I wasn’t using this function.
A

[Ben Goodrich]

Can you crash it from Terminal?

[Andrew Gelman]

I can (and have) crashed the R terminal using Stan.  I don’t know if I can crash the Mac unix terminal using Stan.

[Ben Goodrich]

If you crash R with Stan from the Terminal application, it should at least print a crash message.

On Saturday, July 19, 2014 3:39:06 PM UTC-4, Andrew Gelman wrote:

I can (and have) crashed the R terminal using Stan.  I don’t know if I can crash the Mac unix terminal using Stan.

[Bob Carpenter]

Given that you haven't given us any way to diagnose
the problems you're having, we're grasping at straws
here.

Could you start using the terminal version so you get
an error dump at least the next time this happens.

- Bob

[Andrew Gelman]

Hi, just to be clear: I’ve said all along that the problem is hard for me to reproduce, that I’m working on tracking it down, and I’ll let you know when I can reproduce it. I’m not asking you to diagnose anything.
A

[Ben Goodrich]

A reproducible example would be nice, but one crash message from Terminal would be a great step forward from where we are now. If you have any .R file that has ever caused a crash, you can execute in Terminal

while true; do
R --quiet --no-save --file=crash.R || break
done

and wait until the crash. Then post whatever was the output of the last attempt.

Ben

>>>>>> email to stan-users+unsubscribe@googlegroups.com.

>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google Groups "Stan users mailing list" group.

>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to stan-users+unsubscribe@googlegroups.com.

>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to a topic in the Google Groups "Stan users mailing list" group.
>>>> To unsubscribe from this topic, visit https://groups.google.com/d/topic/stan-users/D3p1FTu3U1M/unsubscribe.

>>>> To unsubscribe from this group and all its topics, send an email to stan-users+unsubscribe@googlegroups.com.

>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google Groups "Stan users mailing list" group.

>>>> To unsubscribe from this group and stop receiving emails from it, send an email to stan-users+unsubscribe@googlegroups.com.

>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "Stan users mailing list" group.

>>> To unsubscribe from this group and stop receiving emails from it, send an email to stan-users+unsubscribe@googlegroups.com.

>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups "Stan users mailing list" group.

>> To unsubscribe from this group and stop receiving emails from it, send an email to stan-users+unsubscribe@googlegroups.com.

>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups "Stan users mailing list" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to stan-users+unsubscribe@googlegroups.com.

[Bob Carpenter]

The reason we're hounding you is that we need to diagnose
the problem if RStan is crashing R so that we can fix the
problem --- right now, we have nothing to go on.

As far as we know, nobody else is having the same kind of
problem. If you are reading this and are seeing calls to RStan
crash R please let us know, especially if you can provide some
output, or even better, a reproducible example.

Did this happen when you (Andrew) were working with the borrowed
machine, too? That would probably rule out a hardware problem.

I know you've said it's hard to reproduce and that you don't
have an R script that will crash Stan when run from a fresh
start of R. That's what makes me think it must be some kind of
statefulness in R itself or your hardware.

As Ben points out, it'd be really helpful if you could
switch to using the terminal version of R for the time
being, then if R crashes, send us the full output that's
printed out by the terminal.

The tedious thing to do would be to keep a *complete* record
of everything you run from the start. Just keep appending it
to a script in a file somewhere, so that we can run the whole
thing.

- Bob

[Andrew Gelman]

Bob
The difficulty of keeping a complete record is that (a) I do a lot of things using random numbers, and (b) I overwrite things. For example, if I have a stan model foo.stan and I find a typo in it, I just change foo.stan, I don’t create a new file name each time I fix the model. Also, the crashing is intermittent and right now in fact I’m not able to reproduce it. But I’ll let you know next time it happens.
A

[Bob Carpenter]

You could still script it, but it'd be a pain. But
if Stan is really crashing on you all the time as you
say, it shouldn't be that much work. And even if
the below steps are too hard, maybe you could use the terminal,
since you said it crashed as much there as in RStudio.
Then at least we'd have some clue to go on from the stack
trace.

Your (a) is no problem --- you just need to set a seed
in both R and Stan so the pseudo-random behavior is
reproducible.

Your (b) is harder. You need to create a snapshot of each
of your edited versions, and swap them in at the appropriate
time. Otherwise, it wouldn't be an exact
dupe and wouldn't catch issues, say, with dynamically linking
models of the same name.

Just think of these steps as being the software equivalent of model
checking. It's a huge pain compared to just running a model, but
necessary if you want to diagnose problems. And diagnosing problems
is the only way to fix them.

You could, of course, solve your problem by restarting R before
each command and re-running the script from scratch, but we want
to fix the underlying problem, assuming there still is one.

- Bob

[Noah Motion]

I have a Stan model that crashes RStudio using RStan. A friend got it to work using CmdStan, so I gave up trying to get it to work in R. I'm at a conference right now, but when I get back home, I will see if I can reproduce the crash using R from the terminal. If so, I'll send the crash message.

Noah Silbert

[Bob Carpenter]

Thanks --- that'd be super helpful. Then we can try
it in various R interfaces and isolate whether it's in
our R or Rcpp code or something to do with the interfaces
we'll have to try to work around.

- Bob