Erreur: nombre maximal de DLL atteint
J'écris un package R qui dépend de nombreux autres packages. Lorsque je charge trop de packages dans la session, j'obtiens souvent cette erreur:
Error in dyn.load(file, DLLpath = DLLpath, ...) :
unable to load shared object '/Library/Frameworks/R.framework/Versions/3.2/Resources/library/proxy/libs/proxy.so':
`maximal number of DLLs reached...
Ce message Nombre maximal de DLL dépassé dans R a souligné que le problème venait du Rdynload.c du code R de base: #define MAX_NUM_DLLS 100
Existe-t-il un moyen de contourner ce problème, sauf en modifiant et en construisant à partir de la source?
Augmenter ce nombre est bien sûr "possible" ... mais cela coûte aussi un peu (ce qui ajoute à l'empreinte mémoire fixe de R).
Je n'ai pas défini cette limite, mais je suis presque sûr que cela signifiait également que l'utilisateur devait "nettoyer" un peu dans sa session R, c'est-à-dire ne pas charger inutilement les espaces de noms des packages. Je ne peux pas encore imaginer que vous ayez besoin de> 100 paquets | des espaces de noms chargés dans votre session R. OTOH, certains packages ont aujourd'hui une multitude de dépendances, donc je conviens que cela peut au moins se produire accidentellement plus fréquemment que par le passé.
La vraie solution serait bien sûr une amélioration du code qui commence par un nombre relativement petit de structures "DLLinfo" (disons 32), puis alloue plus de lots (de taille disons 32) si nécessaire.
Les correctifs pour les sources R (tronc de développement dans Subversion à https://svn.r-project.org/R/trunk/ ) sont les bienvenus!
---- ajouté le 26 janvier 2017: En attendant, nous avons eu un rapport de bogue public à ce sujet, un correctif proposé (qui n'était pas assez bon: il y a toujours un système d'exploitation dépendant limite sur le nombre de fichiers ouverts), et aujourd'hui ce rapport de bogue a été fermé par le membre principal de R @TomasKalibera qui a implémenté un nouveau code où le nombre maximal de DLL chargées est fixé à
pmax(100, pmin(1000, 0.6* OS_dependent_getrlimit_or_equivalent()))
et ainsi sur Windows et Linux (et pas encore testé, mais "presque sûrement" macOS), la limite devrait être considérablement plus élevée qu'auparavant.
----- Mise à jour # 2 (écrite le 5 janvier 2018):
En octobre 17, le changement ci-dessus a été rendu plus automatique avec le commit suivant dans les sources (de la version de développement de R - seulement!)
r73545 | kalibera | 2017-10-12 14:41:20
Augmentez le nombre de DLL pouvant être chargées par défaut. Si nécessaire, augmentez la limite logicielle sur les fichiers ouverts.
et sur la page d'aide ?dyn.load ( https://stat.ethz.ch/R-manual/R-devel/library/base/html/dynload.html ) le ulimit -n <num_open_files> est maintenant mentionné (section Remarque près du bas).
Vous pourriez donc envisager d'utiliser la version de développement de R jusqu'à ce qu'elle devienne "flux principal" en avril.
Alternativement, vous le faites (dans un terminal/Shell)
ulimit -n 2048
puis démarrez R à partir de ce terminal. Tomas Kalibera l'a mentionné pour travailler sur macOS.
Depuis R 3.4, vous pouvez définir un nombre maximal de DLL différent à l'aide de la variable d'environnement R_MAX_NUM_DLLS. D'après les notes de version:
Le nombre maximal de DLL pouvant être chargées dans R, par exemple via dyn.load () peut maintenant être augmenté en définissant la variable d'environnement R_MAX_NUM_DLLS avant de démarrer R.
J'ai eu ce problème avec la bibliothèque simpleSingleCell en bioconducteur
Sur macOS, vous ne pouvez pas dépasser 256. J'ai donc défini mon .Renviron dans mon répertoire personnel R_MAX_NUM_DLLS = 150