Erreur MatLab: impossible d'ouvrir avec TLS statique
Depuis quelques jours, je reçois constamment la même erreur lors de l’utilisation de MATLAB, ce qui se produit parfois avec dlopen. Je suis assez nouveau chez MATLAB et c’est pourquoi je ne sais pas quoi faire. Google ne semble pas m'aider non plus. Lorsque j'essaie de créer un vecteur propre, je reçois ceci:
Error using eig
LAPACK loading error:
dlopen: cannot load any more object with static TLS
Je reçois aussi ceci en faisant une multiplication:
Error using *
BLAS loading error:
dlopen: cannot load any more object with static TLS
J'ai bien sûr cherché les solutions à ce problème, mais je ne comprends pas trop et je ne sais pas quoi faire. Ce sont des discussions que j'ai trouvées:
- Comment utiliser la bibliothèque BLAS fournie par MATLAB?
- http://www.mathworks.de/de/help/matlab/matlab_external/calling-lapack-and-blas-functions-from-mex-files.html
Quelqu'un peut m'aider s'il vous plaît?
Exemples d'appels de fonction démontrant cette erreur
>> randn(3,3)
ans =
2.7694 0.7254 -0.2050
-1.3499 -0.0631 -0.1241
3.0349 0.7147 1.4897
>> eig(ans)
Error using eig
LAPACK loading error:
dlopen: cannot load any more object with static TLS
C'est bug n ° 961964 de MATLAB connu depuis R2012b (8.0). MATLAB charge dynamiquement certaines bibliothèques avec du TLS statique (stockage local des unités d'exécution, voir par exemple, le compilateur gcc indicateur -ftls-model). Charger trop de ces bibliothèques => il n’ya plus d’espace libre.
Jusqu'ici, la seule solution de mathwork consiste à charger les bibliothèques importantes (!) En les utilisant tôt (elles suggèrent de mettre "un (10) * un (10);" dans startup.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: n’utilisez pas "doc" (le système d’aide graphique)! Je pense que cet utilitaire de documentation (libxul, etc.) utilise beaucoup de mémoire TLS statique.
Voici une mise à jour (2013/12/31)
Tous les tests suivants ont été réalisés avec Fedora 20 (avec glibc-2.18-11.fc20) et Matlab 8.3.0.73043 (version préliminaire R2014a).
Pour plus d'informations sur TLS, voir Ulrich Drepper, Gestion ELF pour le stockage local de threads, version 0.21, 2013, actuellement disponible sur Akkadia et Redhat .
Que se passe-t-il exactement?
MATLAB dynamiquement (avec dlopen) charge plusieurs bibliothèques nécessitant l’initialisation de tls. Toutes ces bibliothèques ont besoin d'un emplacement dans le dtv (vecteur de thread dynamique). Comme MATLAB charge plusieurs de ces bibliothèques de manière dynamique au moment de la compilation/de la liaison, l'éditeur de liens (chez mathworks) n'avait aucune chance de compter les emplacements nécessaires (c'est la partie la plus importante). Il incombe maintenant au chargeur dynamique de bibliothèques de gérer un tel cas au moment de l'exécution. Mais ce n'est pas facile. Pour citer dl-open.c:
Pour le TLS statique, nous devons allouer de la mémoire ici et maintenant. Cela inclut l’allocation de mémoire dans le téléviseur numérique. Mais nous ne pouvons changer aucune télévision numérique autre que la nôtre. Donc, si nous ne pouvons pas garantir qu'il y a de la place dans la télévision numérique, nous ne l'essayons même pas et nous échouons à la charge.
Il existe une constante de temps de compilation (appelée DTV_SURPLUS, voir glibc-source/sysdeps/generic/ldsodefs.h) dans le chargeur de bibliothèque dynamique de glibc pour réserver plusieurs emplacements supplémentaires à ce désordre (chargement dynamique de libs avec du TLS statique dans un multithreading). programme). Dans la version glibc de Fedora 20, cette valeur est 14.
Voici les premières bibliothèques (sous MATLAB) qui avaient besoin d'emplacements DTV 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 de 14 => trop nombreux => pas de slot dans le dtv. C'est ce que le message d'erreur essaie de nous dire et en particulier de mathworks.
Pour mémoire: afin de ne pas violer la licence de MATLAB, je n'ai pas débogué, décompilé ou désassemblé aucune partie des fichiers binaires fournis avec MATLAB. J'ai seulement débogué les fichiers binaires libres et ouverts de Fedora 20 que glissaient MATLAB pour charger dynamiquement les bibliothèques.
Que peut-on faire pour résoudre ce problème?
Il y a 3 options:
(a) Reconstruisez MATLAB et ne chargez pas dynamiquement ces bibliothèques (avec le modèle initial-exec tls) au lieu de les lier (alors l'éditeur de liens peut compter les emplacements requis!)
(b) Reconstruisez ces bibliothèques et assurez-vous qu'elles n'utilisent PAS le modèle initial-exec tls.
(c) Reconstruisez la glibc et augmentez DTV_SURPLUS dans glibc/sysdeps/generic/ldsodefs.h
Bien entendu, les options (a) et (b) ne peuvent être réalisées que par mathworks.
Pour l'option (c), aucune source de MATLAB n'est nécessaire et peut donc être utilisée sans mathworks.
Quel est le statut chez mathworks?
J'ai vraiment essayé d'expliquer cela au "service d'assistance technique de MathWorks". Mais mon impression est la suivante: ils ne me comprennent pas. Ils ont fermé mon ticket d'assistance et suggéré une conversation téléphonique (!) En janvier 2014 avec un responsable de l'assistance technique.
Je ferai de mon mieux pour expliquer cela, mais pour être honnête: je ne suis pas très confiant.
Mise à jour (2014/01/10): Mathworks teste actuellement l'option (b).
Mise à jour (2014/03/19): Pour le fichier libiomp5.so, vous pouvez télécharger une version nouvellement compilée (sans TLS statique) dans mathworks, rapport de bogue 961964 . Et les autres libs? Aucune amélioration là-bas. Ne soyez donc pas surpris d’obtenir "dlopen: impossible de charger un objet avec TLS statique" avec "doc", par exemple. voir rapport de bogue 1003952 .
Redémarrer Matlab a résolu le problème pour moi.
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.
http://www.mathworks.de/support/bugreports/961964 a été mis à jour le 30/01/2014. Il y a un fichier Zip attaché avec 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.
Comme je le constate, il s'agit d'un problème séculaire non encore résolu par MathWorks.
Voici mes deux sous qui ont fonctionné pour moi (quand je voulais des bibliothèques externes IT ++, avec MEX).
Laissez la bibliothèque que vous avez trouvée à l'origine du problème soit "libXYZ.so" et indiquez où il se trouve sur votre système.
La solution consiste à informer MATLAB de charger la bibliothèque spécifique au plus tôt de son démarrage. La raison de cette erreur est apparemment due au manque de créneaux horaires pour cette thread local storage _ aka tls objectif (car ils ont déjà été remplis).
Etant donné que les dernières compilations nécessitaient soudainement une nouvelle bibliothèque qui n'avait pas été chargée auparavant lors de son démarrage, MATLAB renvoie cette erreur.
Dommage que MATLAB ne se soit jamais soucié de résoudre ce problème aussi longtemps.
Heureusement, la solution consiste en une seule commande de terminal très simple.
Les étapes typiques sur une machine Linux doivent être les suivantes:
- Ouvrir l'invite de commande (
Ctrl+Alt+Tdans Ubuntu) - Émettez la commande suivante
export LD_PRELOAD = <PATH-TO-libxyz.so>
par exemple.: export LD_PRELOAD=/usr/local/lib/libitpp.so
- Démarrer matlab à partir du même terminal
matlab &
Lancer votre programme maintenant devrait résoudre le problème, comme c'est le cas pour moi.
Bonne chance!
Référence:
[1] http://au.mathworks.com/matlabcentral/answers/125117-openmp-mex-files-static-tls-problem
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!
J'ai eu le même problème avec Matlab 2013b et Matlab 2014a. Le correctif fourni par mathworks pour libiomp5.so ne faisait que supprimer le problème de LAPACK qui ne fonctionnait pas. Cependant, je ne pouvais pas utiliser de bibliothèques externes utilisant OpenMp (telles que VL_FEAT): je reçois toujours le message d'erreur "dlopen: impossible de charger un autre objet avec TLS statique".
La seule chose qui a fonctionné pour moi a été rétrogradée à Matlab 2012b.
Je suis tombé sur ce problème après "bar" (pour les graphiques en barres) avec un tableau qui ne me donne qu'un seul bloc bleu, sans erreur. Le redémarrage a d'abord résolu le problème. Mais après une erreur de mémoire (après avoir traité un très gros fichier), je ne peux tout simplement pas aller au-delà de ce problème de bloc bleu.
L'utilisation de "hist" sur une entrée de matrice me donne le problème "Erreur de chargement BLAS" et m'a amené à ce fil. La solution de contournement de Mathwork a corrigé les problèmes hist et bar.
Je voulais juste faire reconnaître l'ampleur de l'influence de ce bug.
L'augmentation Java (jusqu'à 512 Mo) fonctionnait également pour moi sur R2013b/Ubuntu 12.04. L'erreur "Erreur de chargement BLAS" a commencé lorsque j'ai traité un fichier de 11 Go (avec 16 Go de RAM), ne s'est pas reproduit après l'augmentation de la mémoire Java et le redémarrage de matlab.
J'ai eu le même problème et l'ai résolu en augmentant ma mémoire Java Heap. Allez dans Préférences> Général> Mémoire Java Heap et augmentez la mémoire allouée.