To błąd nr 961964 MATLAB znany od wersji R2012b (8.0). MATLAB dynamicznie ładuje niektóre biblioteki ze statycznym TLS (lokalna pamięć wątków, np. Zobacz flagę kompilatora gcc -ftls-model). Ładowanie zbyt wielu takich bibliotek => brak miejsca.
Do tej pory jedynym rozwiązaniem w pracy matematycznej było załadowanie najpierw ważnych (!) Bibliotek, używając ich wcześnie (sugerują umieszczenie „one (10) * one (10);” w startup.m). Lepiej nie komentować tej „strategii rozwiązania”.
Od wersji R2013b (8.2.0.701) z Linuksem x86_64 moje doświadczenie jest następujące: Nie używaj „doc” (graficznego systemu pomocy)! Myślę, że to narzędzie doc (libxul itp.) Używa dużo statycznej pamięci TLS.
Oto aktualizacja (2013/12/31)
Wszystkie poniższe testy zostały wykonane w Fedorze 20 (z glibc-2.18-11.fc20) i Matlab 8.3.0.73043 (R2014a Prerelease).
Aby uzyskać więcej informacji na temat protokołu TLS, zobacz Ulrich Drepper, obsługa ELF dla lokalnego magazynu wątków, wersja 0.21, 2013, obecnie dostępna w Akkadia i Redhat .
Co się dokładnie dzieje?
MATLAB dynamicznie (z dlopen) ładuje kilka bibliotek, które wymagają inicjalizacji tls. Wszystkie te biblioteki wymagają gniazda w dtv (dynamiczny wektor wątku). Ponieważ MATLAB ładuje kilka z tych bibliotek dynamicznie w czasie wykonywania w czasie kompilacji / łączenia, konsolidator (w Mathworks) nie miał szansy policzyć potrzebnych gniazd (to ważna część). Teraz zadaniem dynamicznego programu ładującego biblioteki jest obsłużyć taki przypadek w czasie wykonywania. Ale to nie jest łatwe. Aby zacytować dl-open.c:
W przypadku statycznego protokołu TLS musimy przydzielić pamięć tu i teraz. Obejmuje to przydzielanie pamięci w DTV. Ale nie możemy zmienić żadnego DTV poza naszym własnym. Tak więc, jeśli nie możemy zagwarantować, że w DTV jest miejsce, nawet nie próbujemy i nie zawiedziemy obciążenia.
Istnieje stała czasowa kompilacji (nazywana DTV_SURPLUS, patrz glibc-source / sysdeps / generic / ldsodefs.h) w dynamicznym programie ładującym biblioteki glibc do rezerwowania wielu dodatkowych gniazd na taki bałagan (dynamiczne ładowanie bibliotek ze statycznym TLS w wielowątkowości program). W Fedorze 20 w wersji glibc ta wartość wynosi 14.
Oto pierwsze biblioteki (z systemem MATLAB), które w moim przypadku potrzebowały slotów dtv:
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
Tak, więcej niż 14 => za dużo => brak miejsca w dtv. Właśnie to próbuje nam przekazać komunikat o błędzie, a zwłaszcza prace matematyczne.
Dla przypomnienia: aby nie naruszyć licencji MATLAB-a, nie debugowałem, nie dekompilowałem ani nie dezasemblowałem żadnej części plików binarnych dostarczonych z MATLAB-em. Debugowałem tylko bezpłatne i otwarte pliki binarne glibc Fedory 20, których MATLAB używał do dynamicznego ładowania bibliotek.
Co można zrobić, aby rozwiązać ten problem?
Istnieją 3 opcje:
(a) Przebuduj MATLAB i nie ładuj dynamicznie tych bibliotek (z modelem Initial-exec tls), zamiast tego połącz się z nimi (wtedy konsolidator może policzyć wymagane sloty!)
(b) Przebuduj te biblioteki i upewnij się, że NIE używają one modelu initial-exec tls.
(c) Przebuduj glibc i zwiększ DTV_SURPLUS w glibc / sysdeps / generic / ldsodefs.h
Oczywiście opcje (a) i (b) mogą być wykonane tylko przez matematykę.
Dla opcji (c) nie jest potrzebne żadne źródło MATLAB-a, a zatem można to zrobić bez pracy matematycznej.
Jaki jest status w firmie Mathworks?
Naprawdę starałem się to wyjaśnić "Działowi pomocy technicznej MathWorks". Ale mam wrażenie: oni mnie nie rozumieją. Zamknęli moje zgłoszenie do pomocy technicznej i zasugerowali rozmowę telefoniczną (!) W styczniu 2014 roku z kierownikiem pomocy technicznej.
Zrobię co w mojej mocy, aby to wyjaśnić, ale mówiąc szczerze: nie jestem zbyt pewny siebie.
Aktualizacja (2014/01/10): Obecnie Mathworks próbuje opcję (b).
Aktualizacja (2014/03/19): Dla pliku libiomp5.so możesz pobrać nowo skompilowaną wersję (bez statycznego TLS) z mathworks, raport o błędzie 961964 . A inne biblioteki? Żadnej poprawy. Więc nie zdziw się , gdy zobaczysz „dlopen: nie można załadować więcej obiektu ze statycznym TLS” z „doc”, np. Zobacz raport o błędzie 1003952 .