C'est bogue n ° 961964 de MATLAB connu depuis R2012 B (8.0). MATLAB charge dynamiquement certains libs avec des TLS statiques (stockage local du thread, par exemple voir drapeau compilateur gcc-ftls-model). Charger trop de tels fichiers = > il ne reste plus de place.

jusqu'à présent, la seule solution pour mathwork est de charger l'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: N'utilisez pas "doc" (le système d'aide graphique)! Je pense que ce doc-utilitaire (libxul,etc.) utilise beaucoup de mémoire TLS statique.

Voici une mise à jour (31/12/2013)

tous les essais suivants ont été effectués avec Fedora 20 (avec glibc-2.18-11.fc20) et Matlab 8.3.0.73043 (R2014a Prerelease).

pour en savoir plus sur TLS, consultez Ulrich Drepper, elfe manipulation de Thread-Local Storage, Version 0.21, 2013, actuellement disponible à Akkadia et Redhat .

que se passe-t-il exactement?

MATLAB dynamiquement (avec dlopen) charge plusieurs bibliothèques qui ont besoin d'initialisation tls. Tous ces libs ont besoin d'un slot dans le dtv (dynamic thread vector). Étant donné que MATLAB charge plusieurs de ces libs de manière dynamique à l'exécution au moment de la compilation/ 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 du chargeur lib dynamique de gérer un tel cas à l'exécution. Mais ce n'est pas facile. Pour citer dl-ouvert.c:

pour les TLS statiques nous devons allouer la mémoire ici et maintenant. Cela inclut l'attribution de la mémoire dans la TVN. Mais nous on ne peut pas changer une autre DTV que la nôtre. Donc, si nous on ne peut pas garantir qu'il y a de la place dans la TVN. même l'essayer et l'échec de la charge.

il y a une constante de temps de compilation (appelée DTV_SURPLUS, voir glibc-source/sysdeps/generic/ldsodefs.h) dans le chargeur lib dynamique de la glibc pour réserver un certain nombre de slots supplémentaires pour un tel mess (libs de chargement dynamique avec des TLS statiques dans un programme multithreading). Dans la version glibc de Fedora 20, cette valeur est de 14.

Voici les premiers libs (running MATLAB) qui ont eu besoin de slots TVN 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 essaie de nous dire et surtout mathworks.

pour mémoire: afin de ne pas violer la licence de MATLAB, je n'ai ni débogué, ni décompilé, ni démonté aucune partie des binaires livrés avec MATLAB. J'ai seulement débogué les binaires glibc libres et ouverts de Fedora 20 que MATLAB utilisait pour charger dynamiquement les libs.

Ce qui peut être fait, pour résoudre ce problème?

il y a 3 options:

(un) Reconstruire MATLAB et ne pas charger dynamiquement ces libs (avec le modèle TLS initial-exec) à la place lient contre eux (puis le linker peut compter les emplacements nécessaires!)

(b) Reconstruisez ces fichiers et assurez-vous qu'ils n'utilisent pas le modèle TLS initial-exec.

(c) Reconstruire glibc et augmenter DTV_SURPLUS dans la glibc/sysdeps/générique/ldsodefs.h

évidemment les options (a) et (b) ne peuvent être faites que par mathworks.

pour l'option (c) aucune source de MATLAB n'est nécessaire et peut donc être fait sans mathworks.

Quel est le statut à mathworks?

j'ai vraiment essayé d'expliquer cela au"service de support technique de MathWorks". Mais mon impression est qu'ils ne me comprennent pas. Ils ont fermé mon billet de soutien et ont 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 essaye l'option (b).

Update (2014/03/19): pour le fichier libiomp5.vous pouvez donc télécharger une version nouvellement compilée (sans TLS statique) à mathworks, rapport de bogue 961964 . Et les autres libs? Aucun amélioration. Ne soyez donc pas surpris d'obtenir "dlopen: ne peut plus charger d'objet avec des TLS statiques" avec "doc", par exemple voir rapport de bogue 1003952 .

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

courte histoire: dans le répertoire que vous commencez matlab à partir de créer un fichier démarrage.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 joint avec libiomp5.donc Je l'ai testé sur Mageia 4 x86_64 avec Matlab R2013b. Je peux maintenant utiliser la Documentation de Matlab pour ouvrir une démonstration sans aucun problème.

C'est, comme je le vois, un vieux problème non résolu par MathWorks.

Voici mes deux cents, qui ont fonctionné pour moi (quand j'ai voulu it++ bibliothèques externes, avec MEX).

que la bibliothèque que vous avez trouvé être la cause du problème soit " libXYZ.donc", et que vous savez où il se trouve sur votre système.

la solution est d'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 à l'absence d'emplacements pour ce thread local storage alias tls but (en raison de ils ont déjà été remplis).

parce que les dernières compilations nécessitaient soudainement une nouvelle bibliothèque qui n'avait pas été chargée plus tôt lors de son démarrage, MATLAB lance cette erreur.

dommage que MATLAB jamais pris soin de résoudre ce problème si longtemps.

Heureusement, la solution est une commande de terminal unique et très simple.

les étapes typiques sur une machine linux devraient être les suivantes:

1. Ouvrez l'invite de commande ( Ctrl+Alt+T dans Ubuntu)
2. émet la commande suivante:

   export LD_PRELOAD=

p.ex.: export LD_PRELOAD=/usr/local/lib/libitpp.so

3. Démarrer matlab à partir du même terminal

   matlab &

exécuter votre programme maintenant devrait résoudre le problème, comme il est pour mon cas.

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 j'ai résolu.

lors de l'installation de matlab utiliser l'installation personnalisée (Je ne l'ai 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 l'affaire pour moi!

J'ai eu le même problème avec Matlab 2013b et Matlab 2014a. Le correctif fourni par mathworks pour libiomp5.donc seulement enlevé le problème de LAPACK ne fonctionne pas. Cependant, je ne pouvais pas utiliser les bibliothèques externes qui utilisent OpenMp (comme VL_FEAT): j'obtiens toujours l'erreur "dlopen: ne peut plus charger d'objet avec des TLS statiques."

la seule chose qui a fonctionné pour moi était le déclassement à Matlab 2012b.

je suis tombé sur ce problème après" bar " (pour les tracés de barre) avec un tableau me donne juste un seul bloc bleu, sans erreurs lancées. 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 pas passer ce problème de bloc bleu.

L'utilisation de" hist "sur une entrée de matrice me donne le problème" BLAS erreur de chargement " et m'a conduit à ce thread. La solution mathématique a permis de résoudre les problèmes d'hist et de barre.

voulait juste apporter la reconnaissance à l'ampleur de l'influence de ce bug.

j'ai eu le même problème et je l'ai résolu en augmentant ma mémoire Java Heap. Allez à préférences > General > Java-Heap Memory, et augmentez la mémoire allouée.

l'Augmentation de Java segment de mémoire (512 mo) a également travaillé pour moi sur R2013b/Ubuntu 12.04. L '"erreur de chargement BLAS" a commencé lorsque j'ai traité un fichier de 11 Go (avec 16 Go de RAM), et ne s'est pas répétée après avoir augmenté la mémoire java heap et redémarré matlab.