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