Error: Maximal Number of Dlls Reached

Error: Maximal number of DLLs reached

Increasing that number is of course "possible"... but it also costs a bit
(adding to the fixed memory footprint of R).

I did not set that limit, but I'm pretty sure it was also meant as reminder for the useR to "clean up" a bit in her / his R session, i.e., not load package namespaces unnecessarily. I cannot yet imagine that you need > 100 packages | namespaces loaded in your R session.
OTOH, some packages nowadays have a host of dependencies, so I agree that this at least may happen accidentally more frequently than in the past.

The real solution of course would be a code improvement that starts with a relatively small number of "DLLinfo" structures (say 32), and then allocates more batches (of size say 32) if needed.

Patches to the R sources (development trunk in subversion at https://svn.r-project.org/R/trunk/ ) are very welcome!

---- added Jan.26, 2017: In the mean time, we've had a public bug report about this, a proposed patch (which was not good enough: There is always an OS dependent limit on the number of open files), and today that bug report has been closed by R core member @TomasKalibera who implemented new code where the maximal number of loaded DLLs is set at

pmax(100, pmin(1000, 0.6* OS_dependent_getrlimit_or_equivalent()))

and so on Windows and Linux (and not yet tested, but "almost surely" macOS), the limit should be considerably higher than previously.

----- Update #2 (written Jan.5, 2018):

In Oct'17, the above change was made more automatic with the following commit to the sources (of the development version of R - only!)

r73545 | kalibera | 2017-10-12 14:41:20

Increase the number of DLLs that can be loaded by default. If needed,
increase the soft limit on open files.

and on the help page ?dyn.load (https://stat.ethz.ch/R-manual/R-devel/library/base/html/dynload.html) the ulimit -n <num_open_files> is now mentioned (section Note close to bottom).

So you might consider using R's development version till that becomes "main stream" in April.

Alternatively, you do (in a terminal / shell)

ulimit -n 2048

and then start R from that terminal. Tomas Kalibera mentioned this to work on macOS.

Maximal number of DLLs reached

Try adding the new environment variable, in System Properties.

Increase max number of DLLs in R Ubuntu from Rstudio

I was looking around, and most solutions are very manual. I liked the editing method here We can fix this from inside R:

install.packages("usethis")
usethis::edit_r_environ()

This will open up an editor for a newly created .Renviron file, where we write in:

R_MAX_NUM_DLLS=256

If you need more than this, you can increase it based on operating system

What this is doing is creating an .Renviron file in your home directory, and creating the R_MAX_NUM_DLLS environment variable, which will be 256 at this point. We can now load up to 256 rather than the default 100.

Exceeded maximum number of DLLs in R

I can't speak for the issues regarding dlls, but you shouldn't need to compile the model each time. You can compile the model once and reuse it, which won't cause this problem and it will speed up your code.

The function stan is a wrapper for stan_model which compiles the model and the sampling method which draws samples from the model. You should run stan_model once to compile the model and save it to an object, and then use the sampling method on that object to draw samples.

require(rstan)

x <- c(1,2)
N <- length(x)

fits <- list()
mod <- stan_model("gp-sim.stan")
for(i in 1:100)
{
    fits[i] <- sampling(mod, data=list(x=x,N=N), iter=1, chains=1)
}

This is similar to the problem of running parallel chains, discussed in the Rstan wiki. Your code could by sped up by replace the for loop with something that processes the sampling in parallel.

How to remove a DLL, aka maximal number of DLLs reached...

This should be fixed in R version > 3.5

https://github.com/rstudio/rstudio/issues/2375#issuecomment-399136011

How to find minimal and maximal address of dll

Use GetModuleInformation, which can accept both an HPROCESS for your remote process and a HMODULE for your injected DLL, and which returns the following information in a MODULEINFO struct:

typedef struct _MODULEINFO {
  LPVOID lpBaseOfDll;
  DWORD  SizeOfImage;
  LPVOID EntryPoint;
} MODULEINFO, *LPMODULEINFO;

So you can know the start address of your injected DLL via the lpBaseOfDll field and the end address via lpBaseOfDll + SizeOfImage.

---

This can also work for a DLL in your current process using GetCurrentProcess and e.g. GetModuleHandle.

Max number of times a DLL can be registered/unregistered?

No there's no maximum. Use Dumpbin.exe or Depends.exe to take a look inside that DLL and check that DllUnRegisterServer entry point is actually defined.

---

Related Topics