Od kilku dni ciągle otrzymuję ten sam błąd podczas korzystania z MATLABa, który zdarza się w pewnym momencie z dlopen. Jestem całkiem nowy w MATLAB-ie i dlatego nie wiem, co robić. Wydaje się, że Google też mi nie pomaga. Kiedy próbuję utworzyć wektor własny, otrzymuję to:

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

Otrzymuję to również podczas wykonywania mnożenia:

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

Szukałem oczywiście rozwiązania tego problemu, ale nie rozumiem zbyt wiele i nie wiem, co robić. Oto wątki, które znalazłem:

1. Jak korzystać z biblioteki BLAS dostarczonej przez MATLAB?
2. http://www.mathworks.de/de/help/matlab/matlab_external/calling-lapack-and-blas-functions-from-mex-files.html

Czy ktoś może mi pomóc, proszę?

Przykłady wywołań funkcji demonstrujących ten błąd

>> 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

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 .

Ponowne uruchomienie Matlaba rozwiązało problem za mnie.

Krótko mówiąc: w katalogu, z którego uruchamiasz matlab, utwórz plik startup.m z zawartością ones(10)*ones(10);. Zrestartuj Matlab i zostanie to załatwione.

Jest to, jak uważam, odwieczny problem, którego MathWorks nie rozwiązał.

Oto moje dwa centy, które mi pomogły (gdy chciałem zewnętrzne biblioteki IT ++ z MEX).

Niech biblioteka, która okazała się przyczyną problemu, to „libXYZ.so” i że wiesz, gdzie ona znajduje się w Twoim systemie.

Rozwiązaniem jest poinformowanie MATLAB-a, aby załadował określoną bibliotekę najwcześniej po uruchomieniu. Przyczyną tego błędu jest podobno ze względu na brak gniazda na tym thread local storageaka tlscelów (ze względu na ich już wypełniona-up).

Ponieważ najnowsze kompilacje nagle wymagały nowej biblioteki, która nie została załadowana wcześniej podczas jej uruchamiania, MATLAB zgłasza ten błąd.

Szkoda, że ​​MATLAB nigdy nie dbał o rozwiązanie tego problemu tak długo.

Na szczęście rozwiązaniem jest jedno, bardzo proste polecenie terminala.

Typowe kroki na komputerze z systemem Linux powinny wyglądać następująco:

1. Otwórz wiersz polecenia ( Ctrl+Alt+Tw Ubuntu)
2. Wydaj następujące polecenie

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

na przykład: export LD_PRELOAD=/usr/local/lib/libitpp.so

3. Uruchom program Matlab z tego samego terminala

   matlab &

Uruchomienie programu teraz powinno rozwiązać problem, tak jak w moim przypadku.

Powodzenia!

Odniesienie:

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

Strona http://www.mathworks.de/support/bugreports/961964 została zaktualizowana 30.01.2014. Do libiomp5 dołączony jest plik zip, więc przetestowałem go na Mageia 4 x86_64 z Matlab R2013b. Mogę teraz korzystać z Dokumentacji Matlaba, aby bez problemu otworzyć wersję demonstracyjną.

Miałem ten sam problem i myślę, że właśnie go rozwiązałem.

Podczas instalacji Matlaba użyj instalacji niestandardowej (nie zrobiłem tego za pierwszym razem). Wybierz tworzenie dowiązań symbolicznych do skryptów Matlab w predefiniowanym folderze (/ usr / local / bin). To załatwiło sprawę dla mnie!

Miałem ten sam problem zarówno z Matlabem 2013b, jak i Matlabem 2014a. Poprawka dostarczona przez mathworks dla libiomp5.so usunęła tylko problem niedziałającego LAPACK-a. Jednak nie mogłem użyć zewnętrznych bibliotek, które używają OpenMp (takich jak VL_FEAT): nadal pojawia się błąd „dlopen: nie można załadować więcej obiektu ze statycznym TLS”.

Jedyną rzeczą, która mi pomogła, było przejście na wersję Matlab 2012b.

Natknąłem się na ten problem po tym, jak "bar" (dla wykresów słupkowych) z tablicą daje mi tylko pojedynczy niebieski blok, bez żadnych błędów. Ponowne uruchomienie najpierw rozwiązało problem. Ale po błędzie pamięci (po przetworzeniu bardzo dużego pliku) po prostu nie mogę obejść tego problemu z niebieskim blokiem.

Użycie "hist" na wejściu macierzy daje mi problem "BLAS loading error" i doprowadził mnie do tego wątku. Obejście Mathwork rozwiązało problemy z hist i słupkiem.

Chciałem tylko zwrócić uwagę na skalę wpływu tego błędu.

Miałem ten sam problem i rozwiązałem go, zwiększając pamięć Java Heap. Przejdź do opcji Preferencje> Ogólne> Pamięć sterty Java i zwiększ przydzieloną pamięć.

Zwiększenie pamięci sterty Java (do 512 MB) działało również dla mnie na R2013b / Ubuntu 12.04. „Błąd ładowania BLAS” zaczął się, gdy przetwarzałem plik 11 GB (z 16 GB RAM) i nie powtórzył się po zwiększeniu pamięci sterty Java i ponownym uruchomieniu Matlaba.