MatLab error: cannot open with static TLS

Question

Since a couple of days, I constantly receive the same error while using MATLAB which happens at some point with dlopen. I am pretty new to MATLAB, and that is why I don't know what to do. Google doesn't seem to be helping me either. When I try to make an eigenvector, I get this:

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

I also get this while making a multiplication:

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

I did of course look for the solutions to this problem, but I don't understand too much and don't know what to do. These are threads I found:

1. How do I use the BLAS library provided by MATLAB?
2. http://www.mathworks.de/de/help/matlab/matlab_external/calling-lapack-and-blas-functions-from-mex-files.html

Can someone help me please?

Examples of function calls demonstrating this error

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

Solution 1

That's bug no 961964 of MATLAB known since R2012b (8.0). MATLAB dynamically loads some libs with static TLS (thread local storage, e.g. see gcc compiler flag -ftls-model). Loading too many such libs => no space left.

Until now mathwork's only workaround is to load the important(!) libs first by using them early (they suggest to put "ones(10)*ones(10);" in startup.m). I better don't comment on this "solution strategy".

Since R2013b (8.2.0.701) with Linux x86_64 my experience is: Don't use "doc" (the graphical help system)! I think this doc-utility (libxul, etc.) is using a lot of static TLS memory.

Here is an update (2013/12/31)

All the following tests were done with Fedora 20 (with glibc-2.18-11.fc20) and Matlab 8.3.0.73043 (R2014a Prerelease).

For more information on TLS, see Ulrich Drepper, ELF handling For Thread-Local Storage, Version 0.21, 2013, currently available at Akkadia and Redhat.

What happens exactly?

MATLAB dynamically (with dlopen) loads several libraries that need tls initialization. All those libs need a slot in the dtv (dynamic thread vector). Because MATLAB loads several of these libs dynamically at runtime at compile/link time the linker (at mathworks) had no chance to count the slots needed (that's the important part). Now it's the task of the dynamic lib loader to handle such a case at runtime. But this is not easy. To cite dl-open.c:

For static TLS we have to allocate the memory here and now. This includes allocating memory in the DTV. But we cannot change any DTV other than our own. So, if we cannot guarantee that there is room in the DTV we don't even try it and fail the load.

There is a compile time constant (called DTV_SURPLUS, see glibc-source/sysdeps/generic/ldsodefs.h) in the glibc's dynamic lib loader for reserving a number of additional slots for such a mess (dynamically loading libs with static TLS in a multithreading program). In the glibc-Version of Fedora 20 this value is 14.

Here are the first libs (running MATLAB) that needed dtv slots in my case:

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

Yes more than 14 => too many => no slot left in the dtv. That's what the error message tries to tell us and especially mathworks.

For the record: In order not to violate MATLAB's license I didn't debug, decompile or disassemble any part of the binaries shipped with MATLAB. I only debugged the free and open glibc-binaries of Fedora 20 that MATLAB were using to dynamically load the libs.

What can be done, to solve this problem?

There are 3 options:

(a) Rebuild MATLAB and do not dynamically load those libs (with initial-exec tls model) instead link against them (then the linker can count the required slots!)

(b) Rebuild those libs and ensure they are NOT using the initial-exec tls model.

(c) Rebuild glibc and increase DTV_SURPLUS in glibc/sysdeps/generic/ldsodefs.h

Obviously options (a) and (b) can only be done by mathworks.

For option (c) no source of MATLAB is needed and thus can be done without mathworks.

What is the status at mathworks?

I really tried to explain this to the "MathWorks Technical Support Department". But my impression is: they don't understand me. They closed my support ticket and suggested a telephone(!) conversation in January 2014 with a technical support manager.

I'll do my very best to explain this, but to be honest: I'm not very confident.

Update (2014/01/10): Currently mathworks is trying option (b).

Update (2014/03/19): For the file libiomp5.so you can download a newly compiled version (without static TLS) at mathworks, bug report 961964. And the other libs? No improvement there. So don't be suprised to get "dlopen: cannot load any more object with static TLS" with "doc", e.g. see bug report 1003952.

Solution 2

Restarting Matlab solved the problem for me.

Solution 3

long story short: in the directory that you start matlab from create a file startup.m with content ones(10)*ones(10);. Restart matlab and it will be taken care of.

Solution 4

This is, as I find, an age-old problem yet unsolved by MathWorks.

Here are my two cents, which worked for me (when I wanted IT++ external libraries, with MEX).

---

Let the library that you found to be the cause of the problem be "libXYZ.so", and that you know where it lies on your system.

The solution is to inform MATLAB to load the specific library at the earliest of its startup. The reason for this error is apparently due to the lack of slots for this thread local storage aka tls purpose (due to they already been filled-up).

Because the latest compilations suddenly required a new library that was not loaded earlier during its startup, MATLAB throws up this error.

Pity that MATLAB never cared to resolve this problem so long.

Fortunately, the solution is a single, very simple terminal command.

---

Typical steps on a linux-machine should be as follows:

1. Open command prompt (Ctrl+Alt+T in Ubuntu)
2. Issue the following command

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

e.g.: export LD_PRELOAD=/usr/local/lib/libitpp.so

3. Start matlab from the same terminal

   matlab &

Running your program now should resolve the issue, as it is for my case.

Good luck!

---

Reference:

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

Solution 5

http://www.mathworks.de/support/bugreports/961964 has been updated on 30/01/2014. There is a zip file attached with libiomp5.so I tested it on Mageia 4 x86_64 with Matlab R2013b. I can now use the Documentation of Matlab to open a demo without any problem.

View more solutions

Comments

[ztik]

What os do you use? Can you share some source code?

[Hans Meyer]

Thank you for your answer. I am using ubuntu, for an example see above

[MeloMCR]

I can confirm this, in my Fedora 64bit opening documentation will cause an error when loading BLAS. Even after increasing Java Heap Memory to 1Gb (what I think is quite enough) the same thing happens.

[michal]

I can confirm this problem on openSUSE 13.1 (64 bit) and MATLAB R2013b, see here: mathworks.com/matlabcentral/newsreader/view_thread/332791. So far, no viable solution!!!

[flying sheep]

what links does this create? i manually linked all scripts without .sh extension there and the bug is still present.

[Danduk82]

Thanks for the ones(10)*ones(10); in the startup.m file : it solved my problem for the moment. BTW this bug is simply incredible...

[Lakshmi]

pls post the solution also as the link may anytime become inactive.

[robince]

I'm getting this error with my own mex files (compiled with gfortran). Is there any way I can build them differently to avoid this issue? The flags include -fPIC which the docs say should use global-dynamic rather than initial-exec TLS.

[Christoph]

I have seen similar behavior. After the first start, matlab emits the above error message. After restarting, the error does not reappear. The error does reappear after a second restart, and this can be repeated over and over. It intermittently reappears after first, third, fifth, ... start of matlab.

[NKN]

I confirm this problem on Ubuntu 12.04 64bit. And replacing the library with the one in the bug report solved the problem. +1

[flying sheep]

the solution is a file subect to MathWorks’ license. We can’t redistribute it and they built it themselves, so there’s no way to “post the solution”. Other than that, it doesn’t work for me: It should be fixed for R2014b, but I still get the error.

[desmond13]

For me too it solved my problem. But appreciate user2898218 for sharing all that.

[David Gardner]

Fixed in R2014b and later (see the bug report), so upgrading is now another option :) I can confirm that R2015a at least does not have this problem, but I haven't tried with R2014b to know if that is also fixed.

[user2230101]

Works fine for me!! Thanks!

[Temak]

Have the same problem with loading libmwosgserver.so in Matlab 2014a. But worked when I downgraded to Matlab 2013b.

[Sameer]

Didn't work for me on OpenSuse Leap 42.1 with Matlab R2016b

[timotheecour]

this was a workaround for me in a completely different setting: issues.dlang.org/show_bug.cgi?id=17061

[foxfireee]

thanks! the only one solution that worked for me (and the simplest one). I am using some external libraries without source code. The funniest thing is the problem still exists in Matlab 2016b...

[spencer.pinegar]

Gotta love when support doesn't understand the solution for their product! Thanks for the in depth explanation, now I can figure out my TLS issue for non Matlab issues.