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 .