それはバグ番号961964です、R2012b（8.0）以降に知られているMATLABです。MATLABは、静的TLSを使用していくつかのライブラリを動的にロードします（スレッドローカルストレージ、たとえばgccコンパイラフラグ-ftls-modelを参照）。そのようなライブラリをロードしすぎる=>スペースが残っていません。
これまでのmathworkの唯一の回避策は、重要な（！）ライブラリを最初にロードして早期にロードすることです（startup.mに「ones（10）* ones（10）;」を配置することをお勧めします）。この「ソリューション戦略」についてはコメントしないほうがいいです。
Linux x86_64でのR2013b（8.2.0.701）以降、私の経験は次のとおりです。「doc」（グラフィカルヘルプシステム）を使用しないでください！このdoc-utility（libxulなど）は多くの静的TLSメモリを使用していると思います。
これがアップデートです（2013/12/31）
以下のすべてのテストは、Fedora 20（glibc-2.18-11.fc20を使用）およびMatlab 8.3.0.73043（R2014aプレリリース）を使用して実行されました。
TLSの詳細については、Ulrich Drepper、ELF処理For Thread-Local Storage、バージョン0.21、2013を参照してください。現在、AkkadiaとRedhatで入手できます。
正確にはどうなりますか？
MATLABは動的に（dlopenを使用して）tlsの初期化を必要とするいくつかのライブラリをロードします。これらのライブラリはすべて、dtv（動的スレッドベクトル）にスロットが必要です。MATLABは、コンパイル/リンク時に実行時にこれらのライブラリのいくつかを動的にロードするため、リンカー（mathworks）は必要なスロットをカウントする機会がありませんでした（これは重要な部分です）。これで、実行時にこのようなケースを処理するのが動的libローダーのタスクになります。しかし、これは簡単ではありません。dl-open.cを引用するには：
静的TLSの場合、ここと今ここでメモリを割り当てる必要があります。これには、DTVでのメモリの割り当てが含まれます。ただし、自分以外のDTVを変更することはできません。したがって、DTVに余裕があることを保証できない場合は、それを試してロードに失敗することすらありません。
glibcの動的libローダーにはコンパイル時定数（DTV_SURPLUSと呼ばれます。glibc-source/ sysdeps / generic / ldsodefs.hを参照）があり、そのような混乱のために多数の追加スロットを予約します（マルチスレッドで静的TLSを使用してlibを動的にロードします）プログラム）。glibc-バージョンのFedora20では、この値は14です。
私の場合、dtvスロットを必要とした最初のライブラリ（MATLABを実行）は次のとおりです。
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
はい14を超えています=>多すぎます=> dtvにスロットが残っていません。それがエラーメッセージが私たちに伝えようとしていることであり、特にmathworksです。
記録のために：MATLABのライセンスに違反しないために、MATLABに付属のバイナリの一部をデバッグ、逆コンパイル、または逆アセンブルしませんでした。私は、MATLABがライブラリを動的にロードするために使用していたFedora20の無料で開いているglibcバイナリのみをデバッグしました。
この問題を解決するために何ができるでしょうか？
3つのオプションがあります：
（a）MATLABを再構築し、それらのライブラリを動的にロードせず（initial-exec tlsモデルを使用）、代わりにそれらに対してリンクします（その後、リンカーは必要なスロットをカウントできます！）
（b）これらのライブラリを再構築し、initial-exectlsモデルを使用していないことを確認します。
（c）glibcを再構築し、glibc / sysdeps / generic /ldsodefs.hのDTV_SURPLUSを増やします。
明らかに、オプション（a）と（b）はmathworksでのみ実行できます。
オプション（c）の場合、MATLABのソースは必要ないため、mathworksなしで実行できます。
mathworksのステータスはどうなっていますか？
これを「MathWorksテクニカルサポート部門」に説明しようと思いました。しかし、私の印象は、彼らは私を理解していないということです。彼らは私のサポートチケットを閉じ、2014年1月にテクニカルサポートマネージャーとの電話（！）会話を提案しました。
私はこれを説明するために最善を尽くしますが、正直に言うと、私はあまり自信がありません。
更新（2014/01/10）：現在、mathworksはオプション（b）を試行しています。
更新（2014/03/19）：ファイルlibiomp5.soについては、mathworksのバグレポート961964で新しくコンパイルされたバージョン（静的TLSなし）をダウンロードできます。そして他のライブラリ？そこには改善はありません。したがって、「dlopen：静的TLSでこれ以上オブジェクトをロードできません」を「doc」で取得することに驚かないでください。たとえば、バグレポート1003952を参照してください。