matlab libraries lapack blas dlopen

Error de MatLab: no se puede abrir con TLS estático



libraries lapack (10)

Desde hace un par de días, constantemente recibo el mismo error al usar MATLAB, que sucede 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 intento hacer un vector propio, obtengo esto:

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

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

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

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

  1. ¿Cómo uso 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, p. Ej., Consulte el indicador de compilador gcc -ftls-model). Cargando demasiadas libs => sin espacio.

Hasta ahora, la única solución de mathwork es cargar las libs importantes (!) Primero utilizándolas anticipadamente (sugieren poner "ones (10) * ones (10);" en startup.m). Será mejor que no comenten 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 herramienta de documentación (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 (R2014a Prerelease).

Para obtener más información sobre TLS, consulte Ulrich Drepper, manejo de ELF para 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 librerías necesitan una ranura en el dtv (vector de hilo dinámico). Debido a que MATLAB carga varias de estas bibliotecas dinámicamente durante el tiempo de ejecución en compilación / enlace, el enlazador (en mathworks) no tuvo la oportunidad de contar las ranuras necesarias (esa es la parte importante). Ahora es la tarea del cargador de lib dinámico manejar ese caso 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 DTV. Pero no podemos cambiar ninguna DTV que no sea la nuestra. Entonces, si no podemos garantizar que hay espacio en la DTV, ni siquiera lo probamos y fallamos la carga.

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

Aquí están las primeras librerías (que ejecutan MATLAB) que necesitan 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é, descompuse ni desensamblé ninguna parte de los binarios enviados con MATLAB. Solo depuré los glibc-binarios gratuitos y abiertos de Fedora 20 que MATLAB estaba usando para cargar dinámicamente las libs.

¿Qué se puede hacer para resolver este problema?

Hay 3 opciones:

(a) Reconstruya MATLAB y no cargue dinámicamente esas libs (con el modelo initial-exec tls) en su lugar vincule contra ellas (¡entonces el enlazador puede contar las ranuras requeridas!)

(b) Reconstruya esas bibliotecas y asegúrese de que NO estén utilizando el modelo de ejecución inicial.

(c) Reconstruya glibc y aumente DTV_SURPLUS en glibc / sysdeps / generic / ldsodefs.h

Obviamente, las opciones (a) y (b) solo pueden ser realizadas por 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 traté de 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 sincero: no estoy muy seguro.

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

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

Esto es, como lo veo, un problema ancestral aún no resuelto por MathWorks.

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

Deje que la biblioteca que encontró que sea la causa del problema sea "libXYZ.so", y que sepa dónde está en su sistema.

La solución es informar a MATLAB que cargue la biblioteca específica al inicio de su inicio. El motivo de este error aparentemente se debe a la falta de ranuras para este thread local storage también conocido como propósito (debido a que ya se han llenado).

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

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

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

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

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

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

por ejemplo: export LD_PRELOAD=/usr/local/lib/libitpp.so

  1. Comience matlab desde la misma terminal

    Matlab y

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

¡Buena suerte!

Referencia:

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

Incrementar la memoria de almacenamiento dinámico de Java (a 512 mb) también me funcionó 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 ha vuelto a aparecer después de aumentar la memoria del montón de Java y reiniciar el matlab.

Me encontré con este problema después de "barra" (para gráficos de barra) con una matriz que me da solo un bloque azul, sin errores lanzados. 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 de 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 matemática solucionó los problemas de hist y barra.

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

Reiniciar Matlab resolvió el problema 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 librerías externas que están usando 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 la degradación a Matlab 2012b.

Tuve el mismo problema y creo que lo resolví.

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

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

larga historia corta: en el directorio en el que comienzas matlab, crea un archivo startup.m con contenido ones(10)*ones(10); . Reinicie matlab y será solucionado.

http://www.mathworks.de/support/bugreports/961964 se ha actualizado el 30/01/2014. Hay un archivo zip adjunto con libiomp5.so 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.