C’est le bogue n ° 961964 de MATLAB connu depuis R2012b (8.0). MATLAB charge dynamicment certaines librairies avec TLS statique (stockage local de thread, par exemple, voir l’indicateur de compilateur gcc -ftls-model). Charger trop de telles libs => plus d’espace disponible.

Jusqu’à présent, la seule solution de Mathwork consiste à charger les libs importantes (!) D’abord en les utilisant tôt (elles suggèrent de mettre “ones (10) * ones (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é effectués avec Fedora 20 (avec glibc-2.18-11.fc20) et Matlab 8.3.0.73043 (version préliminaire de R2014a).

Pour plus d’informations sur TLS, voir Ulrich Drepper, Gestion ELF pour Thread-Local Storage, version 0.21, 2013, actuellement disponible chez Akkadia et Redhat .

Qu’est-ce qui se passe exactement?

MATLAB dynamicment (avec dlopen) charge plusieurs bibliothèques qui nécessitent une initialisation tls. Toutes ces librairies ont besoin d’un slot dans le vecteur de thread dynamic (dtv). Comme MATLAB charge dynamicment plusieurs de ces librairies lors de la compilation / du lien, l’éditeur de liens (sur mathworks) n’a aucune chance de compter les emplacements nécessaires (c’est la partie importante). Le gestionnaire de lib dynamics doit maintenant gérer un tel cas à l’exécution. Mais ce n’est pas facile. Pour citer dl-open.c:

Pour TLS statique, nous devons allouer 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 aucun téléviseur numérique autre que le 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 échouons à la charge.

Il existe une constante de compilation (appelée DTV_SURPLUS, voir glibc-source / sysdeps / generic / ldsodefs.h) dans le chargeur lib dynamic de la glibc pour réserver un certain nombre de slots supplémentaires (chargement dynamic de librairies avec TLS statique dans un multithreading). programme). Dans la version glibc de Fedora 20, cette valeur est 14.

Voici les premières libs (exécutant MATLAB) nécessitant des slots 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 créneau dans la dtv. C’est ce que le message d’erreur tente de nous dire et surtout mathworks.

Pour mémoire: Afin de ne pas violer la licence de MATLAB, je n’ai pas débogué, décompilé ou désassemblé une partie des fichiers binarys livrés avec MATLAB. J’ai seulement débogué les binarys glibc libres et ouverts de Fedora 20 que MATLAB utilisait pour charger dynamicment les libs.

Que peut-on faire pour résoudre ce problème?

Il y a 3 options:

(a) Reconstruisez MATLAB et ne chargez pas dynamicment ces bibliothèques (avec le modèle tls initial-exec) au lieu de les lier (alors l’éditeur de liens peut compter les emplacements requirejs!)

(b) Reconstruisez ces bibliothèques et assurez-vous qu’elles n’utilisent PAS le modèle tls initial-exec.

(c) Reconstruisez glibc et augmentez DTV_SURPLUS dans glibc / sysdeps / generic / ldsodefs.h

Évidemment, les options (a) et (b) ne peuvent être effectuées que par mathworks.

Pour l’option (c), aucune source de MATLAB n’est nécessaire et peut donc être réalisée sans mathworks.

Quel est le statut chez mathworks?

J’ai vraiment essayé d’expliquer cela au “service d’assistance technique MathWorks”. Mais mon impression est la suivante: ils ne me comprennent pas. Ils ont fermé mon ticket de support et suggéré une conversation téléphonique (!) En janvier 2014 avec un responsable du support 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): Actuellement, mathworks essaie l’option (b).

Mise à jour (19/03/2014): Pour le fichier libiomp5.so, vous pouvez télécharger une nouvelle version compilée (sans TLS statique) dans mathworks, rapport de bogue 961964 . Et les autres bibliothèques? Aucune amélioration là-bas. Donc, ne soyez pas surpris d’obtenir “dlopen: ne peut pas charger plus d’objects avec TLS statique” avec “doc”, par exemple voir le rapport de bogue 1003952 .

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

long story en bref: dans le répertoire que vous démarrez matlab, créez un fichier startup.m avec content 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é à 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 aucun problème.

C’est, comme je le trouve, un problème séculaire encore non résolu par MathWorks.

Voici mes deux cents, ce qui a fonctionné pour moi (quand je voulais des bibliothèques externes IT ++, avec MEX).

Laissez la bibliothèque que vous avez trouvée être la cause du problème à “libXYZ.so” et sachez où elle 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 à l’absence de créneaux pour ce thread local storage tls (à cause de leur remplissage).

Les dernières compilations nécessitant soudainement une nouvelle bibliothèque qui n’était pas chargée plus tôt lors de son démarrage, MATLAB génère cette erreur.

Dommage que MATLAB ne se soit jamais soucié de résoudre ce problème aussi longtemps.

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

Les étapes typiques sur une machine Linux doivent être les suivantes:

1. Invite de commande ouverte ( Ctrl+Alt+T dans Ubuntu)
2. Emettez la commande suivante
   

   export LD_PRELOAD =

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

3. Démarrer le matlab depuis le même terminal
   

   matlab &

L’exécution de votre programme maintenant devrait résoudre le problème, comme c’est le cas 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 je viens de le résoudre.

Lors de l’installation de matlab, utilisez l’installation personnalisée (je ne l’ai pas fait la première fois). Choisissez de créer des liens symboliques vers des 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 supprimait que le problème de LAPACK qui ne fonctionnait pas. Cependant, je ne pouvais pas utiliser les bibliothèques externes qui utilisent OpenMp (comme VL_FEAT): j’obtiens toujours l’erreur “dlopen: impossible de charger plus d’objects avec TLS statique”.

La seule chose qui a fonctionné pour moi était la rétrogradation à Matlab 2012b.

Je suis tombé sur ce problème après que “bar” (pour les barres) avec un tableau me donne un seul bloc bleu, sans erreurs. Redémarrez 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 surmonter ce problème de bloc bleu.

L’utilisation de “hist” sur une entrée de masortingce me donne le problème “Erreur de chargement BLAS” et m’a conduit à ce sujet. La solution de contournement Mathwork a résolu les problèmes de hist et de barre.

Je voulais juste apporter une reconnaissance dans la mesure de l’influence de ce bug.

J’ai eu le même problème et l’ai résolu en augmentant ma mémoire Java Heap. Accédez à Preferences> General> Java-Heap Memory et augmentez la mémoire allouée.

L’augmentation de la mémoire de tas Java (jusqu’à 512 Mo) a également fonctionné 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 reproduit après avoir augmenté la mémoire du tas Java et redémarré matlab.