Ответ 1
Что ошибка № 961964 MATLAB, известная с тех пор, как R2012b (8.0). MATLAB динамически загружает некоторые библиотеки со статическим TLS (потоковое локальное хранилище, например, см. Gcc-компилятор flag -ftls-model). Загрузка слишком большого количества таких libs = > осталось пробелов.
До сих пор mathwork только обходной путь заключается в том, чтобы загрузить важные (!) библиотеки сначала, используя их раньше (они предлагают поместить "одни" (10) * одни (10); "в startup.m). Лучше не комментировать эту" стратегию решения".
Так как R2013b (8.2.0.701) с Linux x86_64, мой опыт: Не используйте "doc" (графическая справочная система)! Я думаю, что эта doc-утилита (libxul и т.д.) Использует много статической памяти TLS.
Вот обновление (2013/12/31)
Все следующие тесты были выполнены с Fedora 20 (с glibc-2.18-11.fc20) и Matlab 8.3.0.73043 (R2014a Preerelease).
Для получения дополнительной информации о TLS см. Ульрих Дреппер, обработка ELF для хранилища на основе потоков, версия 0.21, 2013, в настоящее время доступны на Akkadia и Redhat.
Что происходит точно?
MATLAB динамически (с dlopen) загружает несколько библиотек, которые нуждаются в инициализации tls. Все эти библиотеки нуждаются в слоте в dtv (динамический вектор потока). Поскольку MATLAB загружает некоторые из этих библиотек динамически во время выполнения во время компиляции/ссылки, компоновщик (в mathworks) не имел возможности подсчитать требуемые интервалы (что важная часть). Теперь задача динамического загрузчика lib обрабатывать такой случай во время выполнения. Но это непросто. Чтобы привести dl-open.c:
Для статического TLS мы должны выделить память здесь и Теперь. Сюда входит выделение памяти в DTV. Но мы не может изменить DTV, кроме нашего. Итак, если мы не может гарантировать, что в DTV есть место, где нет даже попробуйте и не получите нагрузку.
Существует постоянная времени компиляции (называемая DTV_SURPLUS, см. glibc-source/sysdeps/generic/ldsodefs.h) в динамическом загрузчике lib glibc для резервирования ряда дополнительных слотов для такого беспорядка (динамическая загрузка libs со статическим TLS в программе многопоточности). В glibc-версии Fedora 20 это значение равно 14.
Вот первые libs (запущенные MATLAB), которым нужны слоты 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
Да больше 14 = > слишком много = > в dtv нет слота. Это то, что сообщение об ошибке пытается рассказать нам, и особенно mathworks.
Для записи: чтобы не нарушать лицензию MATLAB, я не отлаживал, не декомпилировал и не разбирал любую часть двоичных файлов, поставляемых с MATLAB. Я только отлаживал бесплатные и открытые glibc-двоичные файлы Fedora 20, которые MATLAB использовал для динамической загрузки libs.
Что можно сделать, чтобы решить эту проблему?
Есть 3 варианта:
(а) Восстановите MATLAB и не динамически загружайте эти библиотеки (с моделью initial-exec tls) вместо этого ссылаются на них (тогда компоновщик может подсчитать требуемые интервалы!)
(б) Перестройте эти библиотеки и убедитесь, что они НЕ используют модель initial-exec tls.
(с) Восстановите glibc и увеличьте DTV_SURPLUS в Glibc/sysdeps/общий/ldsodefs.h
Очевидно, что параметры (a) и (b) могут выполняться только с помощью mathworks.
Для опции (c) источник MATLAB не нужен и, следовательно, может быть выполнен без матчи.
Каков статус в mathworks?
Я действительно попытался объяснить это "Департаменту технической поддержки MathWorks". Но у меня такое впечатление: они меня не понимают. Они закрыли мой билет поддержки и предложили телефон (!) Разговор в январе 2014 года с менеджером технической поддержки.
Я сделаю все возможное, чтобы объяснить это, но, честно говоря, я не очень уверен.
Обновление (2014/01/10): В настоящее время mathworks пытается выбрать вариант (b).
Обновление (2014/03/19): для файла libiomp5.so вы можете загрузить недавно скомпилированную версию (без статического TLS) в mathworks, отчет об ошибке 961964, И другие библиотеки? Никакого улучшения там нет. Поэтому не удивляйтесь, чтобы получить "dlopen: невозможно загрузить больше объекта со статическим TLS" с "doc", например. см. отчет об ошибке 1003952.