Це помилка № 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 Prerelease).
Для отримання додаткової інформації про TLS, див. Ульріх Дреппер, обробка ELF для потокового локального сховища, версія 0.21, 2013, на даний момент доступна в Akkadia та Redhat .
Що саме відбувається?
MATLAB динамічно (з dlopen) завантажує кілька бібліотек, які потребують tls-ініціалізації. Для всіх цих бібліотек потрібен слот у dtv (динамічний вектор потоку). Оскільки MATLAB динамічно завантажує кілька цих бібліотек під час виконання під час компіляції / посилання, компонувальник (у mathworks) не мав шансів підрахувати потрібні слоти (це важлива частина). Тепер завдання динамічного навантажувача бібліотек вирішити такий випадок під час виконання. Але це непросто. Щоб процитувати dl-open.c:
Для статичного TLS ми повинні виділити пам'ять тут і зараз. Сюди входить виділення пам'яті в DTV. Але ми не можемо змінити будь-який DTV, крім нашого. Отже, якщо ми не можемо гарантувати, що в DTV є місце, ми навіть не пробуємо і не справляємо завантаження.
Існує константа часу компіляції (DTV_SURPLUS, див. Glibc-source / sysdeps / generic / ldsodefs.h) в динамічному навантажувачі бібліотек glibc для резервування ряду додаткових слотів для такого безладу (динамічне завантаження бібліотек із статичним 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 і не завантажуйте динамічно ці бібліотеки (з початковою-exec tls-моделлю) замість цього посилання на них (тоді компонувальник може порахувати необхідні слоти!)
(b) Відновіть ці бібліотеки та переконайтеся, що вони НЕ використовують модель початкового виконання.
(c) Відновіть glibc та збільште DTV_SURPLUS у glibc / sysdeps / generic / ldsodefs.h
Очевидно, що варіанти (а) та (b) можуть бути виконані лише математичними роботами.
Для варіанту (c) не потрібно жодне джерело MATLAB, і тому це можна зробити без математичних робіт.
Який статус на математичних роботах?
Я справді намагався пояснити це "Департаменту технічної підтримки MathWorks". Але моє враження таке: вони мене не розуміють. Вони закрили мій квиток на підтримку та запропонували телефонну (!) Розмову в січні 2014 року з менеджером технічної підтримки.
Я докладу максимум зусиль, щоб пояснити це, але чесно кажучи: я не дуже впевнений у собі.
Оновлення (2014/01/10): Наразі mathworks намагається вибрати варіант (b).
Оновлення (2014/03/19): Для файлу libiomp5. так що ви можете завантажити нещодавно скомпільовану версію (без статичного TLS) у mathworks, звіт про помилку 961964 . А інші кінцівки? Поліпшень там немає. Тож не дивуйтеся, щоб отримати "dlopen: не можна більше завантажувати жоден об'єкт із статичним TLS" з "doc", наприклад, див. Звіт про помилку 1003952 .