83 votes

Erreur MatLab: impossible d'ouvrir avec TLS statique

Depuis quelques jours, je ne cesse de recevoir le même message d'erreur lors de l'utilisation de MatLab qui se produit à un certain point avec dlopen. Je suis assez nouveau à MatLab, c'est pourquoi je ne sais pas quoi faire, et google ne peut pas m'aider non plus. Lorsque je tente de faire un vecteur propre, j'obtiens ceci:

Erreur à l'aide de gie LAPACK erreur de chargement: dlopen: impossible de charger plus objet statique TLS

Et aussi en faisant la multiplication:
Erreur à l'aide de * BLAS erreur de chargement: dlopen: impossible de charger plus objet statique TLS

Je n'ai bien sûr chercher les solutions à ce problème, mais je ne comprends pas trop et ne savent pas quoi faire. Ces sont les threads que j'ai trouvé:
Comment puis-je utiliser la bibliothèque BLAS fournis par MATLAB?
http://www.mathworks.de/de/help/matlab/matlab_external/calling-lapack-and-blas-functions-from-mex-files.html

Quelqu'un peut-il m'aider s'il vous plaît?

randn(3,3)

ans =

2.7694 0.7254 -0.2050
-1.3499 -0.0631 -0.1241
3.0349 0.7147 1.4897

gie(sna)

Erreur à l'aide de gie LAPACK erreur de chargement: dlopen: impossible de charger plus objet statique TLS

106voto

user2898218 Points 621

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.

27voto

Wok Points 2020

Redémarrer Matlab a résolu le problème pour moi.

6voto

long story short: dans le répertoire à partir duquel vous démarrez Matlab, créez un fichier startup.m avec le contenu ones(10)*ones(10); . Redémarrez Matlab et il sera pris en charge.

4voto

user3283472 Points 41

http://www.mathworks.de/support/bugreports/961964 a été mis à jour le 30/01/2014. Un fichier zip est joint à libiomp5.so je l’ai testé sur Mageia 4 x86_64 avec Matlab R2013b. Je peux maintenant utiliser la documentation de Matlab pour ouvrir une démo sans problème.

3voto

Anna Points 31

J'ai eu le même problème et je pense que je viens de le résoudre.

Lors de l'installation de matlab, utilisez l'installation personnalisée (je ne l'avais pas fait la première fois). Choisissez de créer des liens symboliques vers les scripts matlab dans le dossier prédéfini (/ usr / local / bin). Cela a fait le tour pour moi!

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X