MatLab-Fehler: Kann nicht mit statischem TLS geöffnet werden

82

Seit ein paar Tagen erhalte ich bei der Verwendung von MATLAB ständig den gleichen Fehler, der irgendwann bei auftritt dlopen. Ich bin ziemlich neu in MATLAB und deshalb weiß ich nicht, was ich tun soll. Google scheint mir auch nicht zu helfen. Wenn ich versuche, einen Eigenvektor zu erstellen, erhalte ich Folgendes:

Error using eig
LAPACK loading error:
dlopen: cannot load any more object with static TLS

Ich bekomme das auch, wenn ich eine Multiplikation mache:

Error using  * 
BLAS loading error:
dlopen: cannot load any more object with static TLS

Ich habe natürlich nach Lösungen für dieses Problem gesucht, aber ich verstehe nicht zu viel und weiß nicht, was ich tun soll. Dies sind Threads, die ich gefunden habe:

  1. Wie verwende ich die von MATLAB bereitgestellte BLAS-Bibliothek?
  2. http://www.mathworks.de/de/help/matlab/matlab_external/calling-lapack-and-blas-functions-from-mex-files.html

Kann mir bitte jemand helfen?

Beispiele für Funktionsaufrufe, die diesen Fehler demonstrieren

>> 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
Hans Meyer
quelle
Welches Betriebssystem benutzt du? Können Sie einen Quellcode teilen?
Ztik
Vielen Dank für Ihre Antwort. Ich benutze Ubuntu, für ein Beispiel siehe oben
Hans Meyer

Antworten:

105

Das ist der Fehler Nr. 961964 von MATLAB, der seit R2012b (8.0) bekannt ist. MATLAB lädt dynamisch einige Bibliotheken mit statischem TLS (lokaler Thread-Speicher, siehe z. B. gcc-Compiler-Flag -ftls-model). Laden zu vieler solcher Bibliotheken => kein Platz mehr.

Bisher besteht die einzige Problemumgehung von mathwork darin, die wichtigen (!) Bibliotheken zuerst zu laden, indem Sie sie frühzeitig verwenden (sie schlagen vor, "one (10) * one (10);" in startup.m zu setzen). Ich kommentiere diese "Lösungsstrategie" besser nicht.

Seit R2013b (8.2.0.701) unter Linux x86_64 ist meine Erfahrung: Verwenden Sie nicht "doc" (das grafische Hilfesystem)! Ich denke, dieses doc-Dienstprogramm (libxul usw.) verwendet viel statischen TLS-Speicher.

Hier ist ein Update (31.12.2013)

Alle folgenden Tests wurden mit Fedora 20 (mit glibc-2.18-11.fc20) und Matlab 8.3.0.73043 (R2014a Prerelease) durchgeführt.

Weitere Informationen zu TLS finden Sie unter Ulrich Drepper, ELF-Handling für threadlokalen Speicher, Version 0.21, 2013, derzeit erhältlich bei Akkadia und Redhat .

Was passiert genau?

MATLAB lädt dynamisch (mit dlopen) mehrere Bibliotheken, die eine TL-Initialisierung benötigen. Alle diese Bibliotheken benötigen einen Slot im dtv (Dynamic Thread Vector). Da MATLAB mehrere dieser Bibliotheken zur Laufzeit zur Kompilierungs- / Verknüpfungszeit dynamisch lädt, hatte der Linker (bei mathworks) keine Chance, die benötigten Slots zu zählen (das ist der wichtige Teil). Jetzt ist es die Aufgabe des Dynamic Lib Loader, einen solchen Fall zur Laufzeit zu behandeln. Das ist aber nicht einfach. Um dl-open.c zu zitieren:

Für statisches TLS müssen wir hier und jetzt den Speicher zuweisen. Dies beinhaltet das Zuweisen von Speicher im DTV. Wir können jedoch keinen anderen DTV als unseren eigenen ändern. Wenn wir also nicht garantieren können, dass im DTV Platz ist, versuchen wir es nicht einmal und versagen beim Laden.

Im dynamischen Lib-Loader von glibc gibt es eine Kompilierungszeitkonstante (DTV_SURPLUS, siehe glibc-source / sysdeps / generic / ldsodefs.h), um eine Reihe zusätzlicher Slots für ein solches Durcheinander zu reservieren (dynamisches Laden von Bibliotheken mit statischem TLS in einem Multithreading) Programm). In der glibc-Version von Fedora 20 ist dieser Wert 14.

Hier sind die ersten Bibliotheken (mit MATLAB), die in meinem Fall dtv-Slots benötigten:

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

Ja mehr als 14 => zu viele => kein Steckplatz mehr im dtv. Das versucht uns die Fehlermeldung zu sagen, insbesondere die Mathematik.

Für die Aufzeichnung: Um die MATLAB-Lizenz nicht zu verletzen, habe ich keinen Teil der mit MATLAB gelieferten Binärdateien debuggt, dekompiliert oder disassembliert. Ich habe nur die freien und offenen Glibc-Binärdateien von Fedora 20 getestet, mit denen MATLAB die Bibliotheken dynamisch geladen hat.

Was kann getan werden, um dieses Problem zu lösen?

Es gibt 3 Möglichkeiten:

(a) Erstellen Sie MATLAB neu und laden Sie diese Bibliotheken nicht dynamisch (mit dem initial-exec tls-Modell), sondern verknüpfen Sie sie mit ihnen (dann kann der Linker die erforderlichen Slots zählen!).

(b) Erstellen Sie diese Bibliotheken neu und stellen Sie sicher, dass sie NICHT das initial-exec tls-Modell verwenden.

(c) Erstellen Sie glibc neu und erhöhen Sie DTV_SURPLUS in glibc / sysdeps / generic / ldsodefs.h

Offensichtlich können die Optionen (a) und (b) nur durch Mathematik ausgeführt werden.

Für Option (c) wird keine MATLAB-Quelle benötigt und kann daher ohne Mathematik ausgeführt werden.

Wie ist der Status bei Mathworks?

Ich habe wirklich versucht, dies der "Abteilung für technischen Support von MathWorks" zu erklären. Aber mein Eindruck ist: Sie verstehen mich nicht. Sie schlossen mein Support-Ticket und schlugen im Januar 2014 ein Telefongespräch (!) Mit einem technischen Support-Manager vor.

Ich werde mein Bestes geben, um dies zu erklären, aber um ehrlich zu sein: Ich bin nicht sehr zuversichtlich.

Update (10.01.2014): Derzeit versucht Mathworks Option (b).

Update (19.03.2014): Für die Datei libiomp5.so können Sie eine neu kompilierte Version (ohne statisches TLS) bei mathworks herunterladen, Fehlerbericht 961964 . Und die anderen Bibliotheken? Keine Verbesserung da. Seien Sie also nicht überrascht, mit "doc" "dlopen: kann kein Objekt mit statischem TLS mehr laden" zu erhalten, siehe z . B. Fehlerbericht 1003952 .

user2898218
quelle
Ich kann dies bestätigen. In meiner Fedora 64-Bit-Eröffnungsdokumentation wird beim Laden von BLAS ein Fehler verursacht. Selbst nach dem Erhöhen des Java-Heap-Speichers auf 1 GB (was meiner Meinung nach völlig ausreicht) passiert dasselbe.
MeloMCR
Ich kann dieses Problem unter openSUSE 13.1 (64 Bit) und MATLAB R2013b bestätigen, siehe hier: mathworks.com/matlabcentral/newsreader/view_thread/332791 . Bisher keine praktikable Lösung !!!
Michal
11
Danke für die (10) * (10); in der Datei startup.m: Es hat mein Problem im Moment gelöst. Übrigens ist dieser Fehler einfach unglaublich ...
Danduk82
Ich erhalte diesen Fehler mit meinen eigenen mex-Dateien (kompiliert mit gfortran). Gibt es eine Möglichkeit, sie anders zu erstellen, um dieses Problem zu vermeiden? Die Flags enthalten -fPIC, von denen die Dokumente sagen, dass sie global-dynamisches TLS anstelle von TLS mit anfänglicher Ausführung verwenden sollten.
Robince
Ich bestätige dieses Problem unter Ubuntu 12.04 64bit. Das Ersetzen der Bibliothek durch die Bibliothek im Fehlerbericht löste das Problem. +1
NKN
27

Ein Neustart von Matlab hat das Problem für mich gelöst.

Wok
quelle
Ich habe ein ähnliches Verhalten gesehen. Nach dem ersten Start gibt matlab die obige Fehlermeldung aus. Nach dem Neustart tritt der Fehler nicht erneut auf. Der Fehler macht wieder auftauchen nach einem zweiten Neustart, und dies kann und über wiederholt über. Es erscheint zeitweise nach dem ersten, dritten, fünften, ... Start von Matlab wieder.
Christoph
1
Auch für mich hat es mein Problem gelöst. Aber schätzen Sie user2898218 für das Teilen all dessen.
Desmond13
Hat bei OpenSuse Leap 42.1 mit Matlab R2016b
Sameer
6

Lange Rede, kurzer Sinn: In dem Verzeichnis, in dem Sie matlab starten, erstellen Sie eine Datei startup.m mit Inhalt ones(10)*ones(10);. Starten Sie matlab neu und es wird erledigt.

Morteza Shahriari Nia
quelle
Funktioniert gut für mich !! Vielen Dank!
user2230101
5

Dies ist, wie ich finde, ein uraltes Problem, das von MathWorks noch nicht gelöst wurde.

Hier sind meine zwei Cent, die für mich funktionierten (als ich externe IT ++ - Bibliotheken mit MEX wollte).


Lassen Sie die Bibliothek, die Sie als Ursache des Problems gefunden haben, "libXYZ.so" sein und wissen, wo sie sich auf Ihrem System befindet.

Die Lösung besteht darin, MATLAB zu informieren, dass die spezifische Bibliothek frühestens beim Start geladen werden soll. Der Grund für diesen Fehler ist anscheinend das Fehlen von Steckplätzen für diesen thread local storagealias tlsZweck (da sie bereits voll sind).

Da für die neuesten Kompilierungen plötzlich eine neue Bibliothek erforderlich war, die beim Start nicht früher geladen wurde, gibt MATLAB diesen Fehler aus.

Schade, dass MATLAB dieses Problem nie so lange gelöst hat.

Glücklicherweise ist die Lösung ein einzelner, sehr einfacher Terminalbefehl.


Typische Schritte auf einem Linux-Computer sollten wie folgt sein:

  1. Öffnen Sie die Eingabeaufforderung ( Ctrl+Alt+Tin Ubuntu)
  2. Geben Sie den folgenden Befehl ein

    export LD_PRELOAD = <PATH-TO-libxyz.so>

z.B: export LD_PRELOAD=/usr/local/lib/libitpp.so

  1. Starten Sie matlab vom selben Terminal aus

    Matlab &

Wenn Sie Ihr Programm jetzt ausführen, sollte das Problem behoben sein, wie es in meinem Fall der Fall ist.

Viel Glück!


Referenz:

[1] http://au.mathworks.com/matlabcentral/answers/125117-openmp-mex-files-static-tls-problem

Liebt Wahrscheinlichkeit
quelle
Dies war eine Problemumgehung für mich in einer völlig anderen Umgebung: issue.dlang.org/show_bug.cgi?id=17061
timotheecour
Vielen Dank! Die einzige Lösung, die für mich funktioniert hat (und die einfachste). Ich verwende einige externe Bibliotheken ohne Quellcode. Das lustigste ist, dass das Problem in Matlab 2016b immer noch besteht ...
foxfireee
4

http://www.mathworks.de/support/bugreports/961964 wurde am 30/01/2014 aktualisiert. Es ist eine Zip-Datei mit libiomp5 angehängt. Ich habe sie auf Mageia 4 x86_64 mit Matlab R2013b getestet. Ich kann jetzt die Dokumentation von Matlab verwenden, um problemlos eine Demo zu öffnen.

user3283472
quelle
1
Bitte veröffentlichen Sie die Lösung auch, da der Link jederzeit inaktiv werden kann.
Lakshmi
Die Lösung ist eine Datei, die der MathWorks-Lizenz unterliegt. Wir können es nicht weitergeben und sie haben es selbst erstellt, daher gibt es keine Möglichkeit, die Lösung zu veröffentlichen. Davon abgesehen funktioniert es bei mir nicht: Es sollte für R2014b behoben sein, aber ich erhalte immer noch den Fehler.
fliegende Schafe
3

Ich hatte das gleiche Problem und ich denke, ich habe es gerade gelöst.

Verwenden Sie bei der Installation von matlab die benutzerdefinierte Installation (ich habe dies nicht beim ersten Mal getan). Wählen Sie, ob Sie symbolische Links zu Matlab-Skripten im vordefinierten Ordner (/ usr / local / bin) erstellen möchten. Das hat den Trick für mich getan!

Anna
quelle
Welche Links entstehen dadurch? Ich habe dort manuell alle Skripte ohne die Erweiterung .sh verlinkt und der Fehler ist immer noch vorhanden.
fliegende Schafe
3

Ich hatte das gleiche Problem mit Matlab 2013b und Matlab 2014a. Das von mathworks für libiomp5.so bereitgestellte Update hat nur das Problem behoben, dass LAPACK nicht funktioniert. Ich konnte jedoch keine externen Bibliotheken verwenden, die OpenMp verwenden (z. B. VL_FEAT): Ich erhalte weiterhin die Fehlermeldung "dlopen: Objekt kann nicht mehr mit statischem TLS geladen werden."

Das einzige, was für mich funktioniert hat, war ein Downgrade auf Matlab 2012b.

Jasper Uijlings
quelle
Haben Sie das gleiche Problem beim Laden von libmwosgserver.so in Matlab 2014a. Aber es hat funktioniert, als ich auf Matlab 2013b heruntergestuft habe.
Temak
2

Ich bin auf dieses Problem gestoßen, nachdem "bar" (für Balkendiagramme) mit einem Array mir nur einen einzigen blauen Block ohne Fehler gegeben hat. Neustart löste zuerst das Problem. Aber nach einem Speicherfehler (nach der Verarbeitung einer sehr großen Datei) kann ich dieses Problem mit dem blauen Block einfach nicht überwinden.

Die Verwendung von "hist" für eine Matrixeingabe führt zu dem Problem "BLAS-Ladefehler" und führte mich zu diesem Thread. Die Mathwork-Problemumgehung hat die Hist- und Balkenprobleme behoben.

Ich wollte nur das Ausmaß des Einflusses dieses Fehlers anerkennen.

Asy
quelle
0

Ich hatte das gleiche Problem und löste es, indem ich meinen Java-Heap-Speicher vergrößerte. Gehen Sie zu Einstellungen> Allgemein> Java-Heap-Speicher und erhöhen Sie den zugewiesenen Speicher.

Justin
quelle
0

Das Erhöhen des Java-Heapspeichers (auf 512 MB) funktionierte auch für mich unter R2013b / Ubuntu 12.04. Der "BLAS-Ladefehler" begann, als ich eine 11-GB-Datei (mit 16 GB RAM) verarbeitete, und trat nach dem Erhöhen des Java-Heap-Speichers und dem Neustart von matlab nicht mehr auf.

Michael Knight
quelle