C'est un bug pas 961964 de MATLAB connu depuis R2012b (8.0). MATLAB charge dynamiquement certaines libs statiques de TLS (thread local storage, voir, par exemple, le compilateur gcc drapeau -ftls-modèle). Chargement trop grand nombre de ces libs => pas d'espace à gauche.
Jusqu'à maintenant mathwork la seule solution est de charger le important(!) libs d'abord par l'aide plus tôt (ils suggèrent de mettre "(10)*(10);" au démarrage.m). Je ferais mieux de ne pas commenter cette "stratégie de solution".
Depuis R2013b (8.2.0.701) avec Linux x86_64 mon expérience est la suivante: Ne pas utiliser "doc" (l'interface graphique du système d'aide)! Je pense que ce doc-utilitaire (libxul, etc.) est avec beaucoup de statique de la mémoire TLS.
Voici une mise à jour (2013/12/31)
Tous les tests suivants ont été effectués avec Fedora 20 (avec glibc-2.18-11.fc20) et Matlab 8.3.0.73043 (R2014a Préliminaire).
Pour plus d'informations sur le protocole TLS, voir
Ulrich Drepper, ELFE de la manutention Pour le Stockage Local de Threads, la Version de 0,21, 2013,
actuellement disponible à Akkadia et Redhat.
Ce qui se passe exactement?
MATLAB dynamiquement (avec dlopen) charges de plusieurs bibliothèques de tls initialisation. Tous ces libs besoin d'un logement, dans le tvn (thread dynamique vecteur). Parce que MATLAB charge plusieurs de ces libs dynamiquement à l'exécution lors de la compilation/lien le temps que l'éditeur de liens (mathworks) n'avait aucune chance de compter les emplacements nécessaires (c'est la partie importante). Maintenant, c'est la tâche de la dynamique lib chargeur pour traiter un tel cas, au moment de l'exécution. Mais ce n'est pas facile. Pour citer dl-ouvert.c:
Pour statique TLS nous avons pour allouer de la mémoire, ici et
maintenant. Cela inclut l'allocation de mémoire dans le TVN. Mais nous
ne peut pas changer de TVN, autres que les nôtres. Donc, si nous
ne peut pas garantir qu'il n'y a de place dans le TVN nous n'avons pas
même l'essayer et échouer la charge.
Il y a un moment de la compilation constante (appelé DTV_SURPLUS, voir glibc-source/sysdeps/générique/ldsodefs.h) dans la glibc dynamique lib chargeur pour réserver un certain nombre de fentes supplémentaires pour un tel gâchis (chargement dynamique de libs statiques de TLS dans un multithreading programme). Dans la glibc Version de Fedora 20 cette valeur est de 14.
Voici la première libs (l'exécution de MATLAB) dtv fentes dans mon cas:
matlabroot/bin/glnxa64/libut.so
/lib64/libstdc++.so.6
/lib64/libpthread.so.0
matlabroot/bin/glnxa64/libunwind.so.8
/lib64/libuuid.so.1
matlabroot/sys/java/jre/glnxa64/jre/lib/amd64/server/libjvm.so
matlabroot/sys/java/jre/glnxa64/jre/lib/amd64/libfontmanager.so
matlabroot/sys/java/jre/glnxa64/jre/lib/amd64/libt2k.so
matlabroot/bin/glnxa64/mkl.so
matlabroot/sys/os/glnxa64/libiomp5.so
/lib64/libasound.so.2
matlabroot/sys/jxbrowser/glnxa64/xulrunner/xulrunner-linux-64/libxul.so
/lib64/libselinux.so.1
/lib64/libpixman-1.so.0
/lib64/libEGL.so.1
/lib64/libGL.so.1
/lib64/libglapi.so.0
Oui plus que 14 => trop d' => pas de fente gauche dans le tvn. C'est ce que le message d'erreur tente de nous expliquer et surtout de mathworks.
Pour l'enregistrement: afin de ne pas violer MATLAB licence je n'ai pas de débogage, décompiler ou désassembler toute partie du binaires avec MATLAB. Je ne débogué le libre et ouvert glibc-binaires de Fedora 20 que MATLAB ont été à l'aide de charger dynamiquement les libs.
Ce qui peut être fait pour résoudre ce problème?
Il y a 3 options:
(a)
Reconstruction de MATLAB et de ne pas charger dynamiquement ces libs
(avec initiale-exec modèle tls) au lieu de liaison contre eux (alors que l'éditeur de liens
compter le nombre de slots requis!)
(b)
Reconstruire ces libs et de s'assurer qu'ils ne sont PAS à l'aide de la première-exec tls modèle.
(c)
Reconstruction de la glibc et augmenter DTV_SURPLUS dans
la glibc/sysdeps/générique/ldsodefs.h
Évidemment options (a) et (b) peuvent être effectuées uniquement par mathworks.
Pour l'option (c) aucune source de MATLAB est nécessaire et peut donc se faire sans mathworks.
Quel est le statut de mathworks?
J'ai vraiment essayé de l'expliquer à la "MathWorks Service de Support Technique". Mais mon impression est: ils ne me comprennent pas. Ils ont fermé mon ticket de support et a suggéré un téléphone(!) conversation en janvier 2014 avec un responsable du support technique.
Je vais faire de mon mieux pour expliquer cela, mais pour être honnête: je ne suis pas très confiant.
Mise à jour (2014/01/10): Actuellement mathworks est d'essayer de l'option (b).
Mise à jour (2014/03/19): Pour le fichier libiomp5.ainsi, vous pouvez télécharger une nouvelle version compilée (sans statique TLS) au mathworks, rapport de bug 961964. Et les autres libs? Pas d'amélioration. Ne soyez donc pas surpris de recevoir "dlopen: impossible de charger plus d'objet statique TLS", "doc", voir, par exemple, rapport de bug 1003952.
