Что ошибка № 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.

Перезапуск Matlab решил проблему для меня.

длинный рассказ короткий: в директории, в которой вы запускаете matlab, создайте файл  startup.m с содержимым ones(10)*ones(10);. Перезагрузите matlab, и о нем позаботятся.

http://www.mathworks.de/support/bugreports/961964 обновлено 30/01/2014. Существует zip файл с libiomp5.so Я тестировал его на Mageia 4 x86_64 с Matlab R2013b. Теперь я могу использовать документацию Matlab, чтобы открыть демонстрацию без каких-либо проблем.

Это, как я нахожу, старую проблему, еще не решенную MathWorks.

Вот мои два цента, которые работали для меня (когда мне нужны внешние библиотеки Microsoft ++, с MEX).

Пусть библиотека, которую вы обнаружили причиной проблемы, - "libXYZ.so", и что вы знаете, где она лежит в вашей системе.

Решение состоит в том, чтобы сообщить MATLAB, чтобы загрузить конкретную библиотеку в самое раннее время ее запуска. Причина этой ошибки, по-видимому, связана с отсутствием слотов для этой цели thread local storage aka tls (из-за того, что они уже были заполнены).

Поскольку последние компиляции внезапно потребовали новую библиотеку, которая ранее не загружалась во время запуска, MATLAB вызывает эту ошибку.

Жаль, что MATLAB так долго не заботился о том, чтобы решить эту проблему.

К счастью, решение - это простая, очень простая команда терминала.

Типичные шаги на linux-машине должны быть следующими:

• Откройте командную строку (Ctrl+Alt+T в Ubuntu)
• Выполните следующую команду

  экспортировать LD_PRELOAD = < PATH-TO-libxyz.so >

например: export LD_PRELOAD=/usr/local/lib/libitpp.so

3. Запустите matlab с того же терминала

   matlab &

Запуск вашей программы теперь должен решить проблему, как и для моего случая.

Удачи!

Ссылка:

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

У меня была та же проблема с Matlab 2013b и Matlab 2014a. Исправление, предоставленное mathworks для libiomp5.so, только устранило проблему LAPACK, которая не работает. Однако я не мог использовать внешние библиотеки, которые используют OpenMp (например, VL_FEAT): я все еще получаю ошибку "dlopen: не может загружать объект со статическим TLS".

Единственное, что сработало для меня, было понижение до Matlab 2012b.

У меня была такая же проблема, и я думаю, что просто решил.

При установке Matlab используйте пользовательскую установку (я не делал этого в первый раз). Выберите создание символических ссылок на скрипты matlab в предопределенной папке (/usr/local/bin). Это помогло!

Я столкнулся с этой проблемой после того, как "bar" (для штриховых графиков) с массивом дает мне только один синий блок, без ошибок. Перезагрузка сначала решила проблему. Но после ошибки памяти (после обработки очень большого файла) я просто не могу преодолеть эту проблему с синим блоком.

Использование "hist" на входе матрицы дает мне ошибку "Ошибка загрузки BLAS" и привело меня к этой теме. Обходное решение Mathwork фиксировало проблемы с гистограммой и барами.

Просто хотел привнести признание в степень влияния этой ошибки.

Увеличение памяти кучи Java (до 512 МБ) также работало для меня на R2013b/Ubuntu 12.04. "Ошибка загрузки BLAS" началась, когда я обработал 11-гигабайтный файл (с 16-гигабайтной оперативной памятью) и не возвращался после увеличения памяти кучи java и перезапуска Matlab.

У меня была такая же проблема, и я решил ее, увеличив свою память Java Heap. Перейдите в раздел "Настройки" > "Основные" > "Память Java-кучи" и увеличьте выделенную память.