Desde hace un par de días, recibo constantemente el mismo error al usar MATLAB, lo que ocurre en algún momento con dlopen. Soy bastante nuevo en MATLAB y es por eso que no sé qué hacer. Google tampoco parece ayudarme. Cuando trato de hacer un vector propio, obtengo esto:

Error using eig
LAPACK loading error:
dlopen: cannot load any more object with static TLS

También obtengo esto mientras hago una multiplicación:

Error using  * 
BLAS loading error:
dlopen: cannot load any more object with static TLS

Por supuesto, busqué las soluciones a este problema, pero no entiendo demasiado y no sé qué hacer. Estos son los hilos que encontré:

1. ¿Cómo utilizo la biblioteca BLAS proporcionada por MATLAB?
2. http://www.mathworks.de/de/help/matlab/matlab_external/calling-lapack-and-blas-functions-from-mex-files.html

¿Puede alguien ayudarme por favor?

Ejemplos de llamadas a funciones que demuestran este error

>> randn(3,3)

ans =

 2.7694    0.7254   -0.2050             
-1.3499   -0.0631   -0.1241             
 3.0349    0.7147    1.4897            

>> eig(ans)

Error using eig
LAPACK loading error:
dlopen: cannot load any more object with static TLS

Ese es el error no 961964 de MATLAB conocido desde R2012b (8.0). MATLAB carga dinámicamente algunas bibliotecas con TLS estático (almacenamiento local de subprocesos, por ejemplo, consulte el indicador del compilador gcc -ftls-model). Cargando demasiadas bibliotecas de este tipo => no queda espacio.

Hasta ahora, la única solución de mathwork es cargar las bibliotecas importantes (!) Primero usándolas antes (sugieren poner "unos (10) * unos (10);" en startup.m). Será mejor que no comente sobre esta "estrategia de solución".

Desde R2013b (8.2.0.701) con Linux x86_64, mi experiencia es: ¡No use "doc" (el sistema de ayuda gráfica)! Creo que esta doc-utility (libxul, etc.) está usando mucha memoria TLS estática.

Aquí hay una actualización (2013/12/31)

Todas las siguientes pruebas se realizaron con Fedora 20 (con glibc-2.18-11.fc20) y Matlab 8.3.0.73043 (versión preliminar de R2014a).

Para obtener más información sobre TLS, consulte Ulrich Drepper, ELF handling For Thread-Local Storage, versión 0.21, 2013, actualmente disponible en Akkadia y Redhat .

¿Qué pasa exactamente?

MATLAB dinámicamente (con dlopen) carga varias bibliotecas que necesitan la inicialización de tls. Todas esas bibliotecas necesitan una ranura en el dtv (vector de hilo dinámico). Debido a que MATLAB carga varias de estas librerías dinámicamente en tiempo de ejecución en tiempo de compilación / enlace, el enlazador (en mathworks) no tuvo la oportunidad de contar las ranuras necesarias (esa es la parte importante). Ahora es tarea del cargador dinámico de bibliotecas manejar un caso de este tipo en tiempo de ejecución. Pero esto no es fácil. Para citar dl-open.c:

Para TLS estático tenemos que asignar la memoria aquí y ahora. Esto incluye la asignación de memoria en la DTV. Pero no podemos cambiar ninguna DTV que no sea la nuestra. Entonces, si no podemos garantizar que haya espacio en la DTV, ni siquiera lo probamos y fallamos la carga.

Hay una constante de tiempo de compilación (llamada DTV_SURPLUS, ver glibc-source / sysdeps / generic / ldsodefs.h) en el cargador dinámico de bibliotecas de glibc para reservar un número de ranuras adicionales para tal desorden (cargando dinámicamente bibliotecas con TLS estático en un subproceso múltiple programa). En la versión glibc de Fedora 20, este valor es 14.

Aquí están las primeras bibliotecas (ejecutando MATLAB) que necesitaban ranuras dtv en mi caso:

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

Sí, más de 14 => demasiados => no queda espacio en el dtv. Eso es lo que el mensaje de error intenta decirnos y especialmente Mathworks.

Para el registro: para no violar la licencia de MATLAB, no depuré, descompillé ni desensamblé ninguna parte de los binarios enviados con MATLAB. Solo depuré los binarios glibc abiertos y gratuitos de Fedora 20 que MATLAB estaba usando para cargar dinámicamente las bibliotecas.

¿Qué se puede hacer para solucionar este problema?

Hay 3 opciones:

(a) Reconstruya MATLAB y no cargue dinámicamente esas bibliotecas (con el modelo initial-exec tls) en lugar de vincularlas (¡entonces el vinculador puede contar las ranuras requeridas!)

(b) Reconstruya esas librerías y asegúrese de que NO estén usando el modelo initial-exec tls.

(c) Reconstruir glibc y aumentar DTV_SURPLUS en glibc / sysdeps / generic / ldsodefs.h

Obviamente, las opciones (a) y (b) solo pueden realizarse con mathworks.

Para la opción (c) no se necesita ninguna fuente de MATLAB y, por lo tanto, se puede hacer sin mathworks.

¿Cuál es el estado en Mathworks?

Realmente intenté explicar esto al "Departamento de Soporte Técnico de MathWorks". Pero mi impresión es: no me entienden. Cerraron mi ticket de soporte y sugirieron una conversación telefónica (!) En enero de 2014 con un gerente de soporte técnico.

Haré todo lo posible para explicar esto, pero para ser honesto: no tengo mucha confianza.

Actualización (2014/01/10): Actualmente, Mathworks está probando la opción (b).

Actualización (19/03/2014): para el archivo libiomp5.so puede descargar una versión recién compilada (sin TLS estático) en mathworks, informe de error 961964 . ¿Y las otras librerías? No hay mejoría allí. Así que no se sorprenda de obtener "dlopen: no se pueden cargar más objetos con TLS estático" con "doc", por ejemplo, consulte el informe de error 1003952 .

Reiniciar Matlab resolvió el problema por mí.

En pocas palabras: en el directorio desde el que inicias matlab, crea un archivo startup.m con contenido ones(10)*ones(10);. Reinicie matlab y se solucionará.

Este es, como encuentro, un problema antiguo aún no resuelto por MathWorks.

Aquí están mis dos centavos, que funcionaron para mí (cuando quería bibliotecas externas IT ++, con MEX).

Deje que la biblioteca que encontró que es la causa del problema sea "libXYZ.so" y sepa dónde se encuentra en su sistema.

La solución es informar a MATLAB que cargue la biblioteca específica lo antes posible desde su inicio. La razón de este error es al parecer debido a la falta de ranuras para este thread local storagealias tlsobjetivo (debido a que ya se ha llenado de seguimiento).

Debido a que las últimas compilaciones de repente requirieron una nueva biblioteca que no se cargó anteriormente durante su inicio, MATLAB arroja este error.

Lástima que MATLAB nunca se haya preocupado por resolver este problema durante tanto tiempo.

Afortunadamente, la solución es un comando de terminal único y muy simple.

Los pasos típicos en una máquina Linux deberían ser los siguientes:

1. Abrir símbolo del sistema ( Ctrl+Alt+Ten Ubuntu)
2. Emita el siguiente comando

   exportar LD_PRELOAD = <PATH-TO-libxyz.so>

p.ej: export LD_PRELOAD=/usr/local/lib/libitpp.so

3. Inicie matlab desde la misma terminal

   matlab y

Ejecutar su programa ahora debería resolver el problema, como es mi caso.

¡Buena suerte!

Referencia:

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

http://www.mathworks.de/support/bugreports/961964 se actualizó el 30/01/2014. Hay un archivo zip adjunto con libiomp5, así que lo probé en Mageia 4 x86_64 con Matlab R2013b. Ahora puedo usar la Documentación de Matlab para abrir una demostración sin ningún problema.

Tuve el mismo problema y creo que simplemente lo resolví.

Al instalar matlab, use la instalación personalizada (no hice esto la primera vez). Elija crear enlaces simbólicos a los scripts de matlab en la carpeta predefinida (/ usr / local / bin). ¡Esto funcionó para mí!

Tuve el mismo problema con Matlab 2013b y Matlab 2014a. La solución proporcionada por mathworks para libiomp5.so solo eliminó el problema de que LAPACK no funcionaba. Sin embargo, no pude usar bibliotecas externas que usan OpenMp (como VL_FEAT): sigo recibiendo el error "dlopen: no puedo cargar más objetos con TLS estático".

Lo único que funcionó para mí fue cambiar a Matlab 2012b.

Me encontré con este problema después de que "bar" (para diagramas de barras) con una matriz me da un solo bloque azul, sin errores. Reiniciar al principio resolvió el problema. Pero después de un error de memoria (después de procesar un archivo muy grande), simplemente no puedo superar este problema del bloque azul.

El uso de "hist" en una entrada de matriz me da el problema de "error de carga BLAS" y me llevó a este hilo. La solución alternativa de Mathwork solucionó los problemas de historial y barra.

Solo quería dar a conocer el alcance de la influencia de este error.

Tuve el mismo problema y lo resolví aumentando mi memoria Java Heap. Vaya a Preferencias> General> Java-Heap Memory y aumente la memoria asignada.

El aumento de la memoria del montón de Java (a 512 mb) también funcionó para mí en R2013b / Ubuntu 12.04. El "error de carga de BLAS" comenzó cuando procesé un archivo de 11 GB (con 16 GB de RAM) y no se repitió después de aumentar la memoria del montón de Java y reiniciar matlab.