Erreur: nombre maximal de DLL atteint

Je suis en train d'écrire un package R qui dépend de nombreux autres packages. Lorsque je charge trop grand nombre de paquets dans la session, j'ai souvent eu 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 post Dépasse le nombre maximum de Dll dans R a souligné que le problème est avec le Rdynload.c de la base de R code:
#define MAX_NUM_DLLS 100

Est-il un moyen de contourner ce problème à l'exception de la modification et de la construction de la source?

source d'informationauteur Qin Zhu

  1. 15

    L'augmentation de ce nombre est naturellement "possible"... mais il coûte aussi un peu
    (s'ajoutant à l'empreinte mémoire fixe de R).

    Je n'ai pas cette limite, mais je suis sûr que c'était aussi perçue comme rappel pour l'utilisateur de "nettoyer" un peu dans son R de la session, c'est à dire, pas de charger le package espaces de noms inutilement. Je ne peux pas encore imaginer que vous avez besoin > 100 colis | espaces de noms chargés dans votre R session.
    Otoh, que, certains paquets ont aujourd'hui une multitude de dépendances, je suis d'accord, c'est du moins ce qui peut arriver accidentellement plus fréquemment que dans le passé.

    La vraie solution serait une les améliorations de code qui commence par un nombre relativement restreint de "DLLinfo" structures (disons 32), puis alloue plus de lots (de la taille de dire 32) si nécessaire.

    De correctifs pour le R sources (développement du tronc dans la subversion à https://svn.r-project.org/R/trunk/ ) sont les bienvenus!

    ---- ajouté le Jan.26, 2017: Dans le temps de le dire, nous avons eu un public rapport de bug à ce sujet, une proposition de patch (qui n'était pas assez bon: Il y a toujours un OS dépendant de limite sur le nombre de fichiers ouverts), et aujourd'hui, ce rapport de bug a été fermé par la R des membres principaux @TomasKalibera qui a mis en place un nouveau code où le nombre maximal de chargement de Dll est fixé à

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

    et donc sur Windows et Linux (et pas encore testé, mais "presque sûrement" macOS), la limite doit être considérablement plus élevé que précédemment.

    ----- Mise à jour #2 (écrit Janv.5, 2018):

    En octobre'17, la modification ci-dessus a été faite plus automatique avec la suite de s'engager aux sources (de la version de développement de la R - seulement!)

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

    Augmenter le nombre de Dll qui peuvent être chargés par défaut. Si nécessaire,
    augmentation de la limite 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 Note fermer vers le bas).

    De sorte que vous pourriez envisager d'utiliser des R de la version de développement jusqu'qui devient "main stream" en avril.

    Alternativement, vous n' (dans un terminal /shell)

    ulimit-n 2048

    et puis commencer à R à partir de ce terminal. Tomas Kalibera mentionné que cela fonctionne sur macOS.

  2. 16

    Que de R 3.4, vous pouvez définir un autre nombre max de la Dll à l'aide et variable d'environnement R_MAX_NUM_DLLS. Depuis les notes de version:

    Le nombre maximum de Dll qui peut être chargé dans R par exemple via
    dyn.load() peut maintenant être augmenté par le réglage de l'environnement
    variable R_MAX_NUM_DLLS avant de commencer R.

  3. 5

    J'ai eu ce problème avec le simpleSingleCell bibliothèque dans bioconductor

    Sur macOS vous ne pouvez pas dépasser 256. J'ai donc mis mon .Renviron dans mon répertoire home
    R_MAX_NUM_DLLS=150

  4. -2

    Il est facile
    Aller à la variable d'environnement et de modifier 

    variable_name = R_MAX_NUM_DLL
value = 1000

    Redémarrer R
    a bien fonctionné pour moi