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


82

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

¿Qué sistema operativo usas? ¿Puedes compartir algún código fuente?
ztik

Gracias por su respuesta. Estoy usando ubuntu, para ver un ejemplo, ver arriba
Hans Meyer

Respuestas:


105

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 .


Puedo confirmar esto, en mi documentación de apertura de Fedora 64bit causará un error al cargar BLAS. Incluso después de aumentar Java Heap Memory a 1Gb (lo que creo que es suficiente) sucede lo mismo.
MeloMCR

Puedo confirmar este problema en openSUSE 13.1 (64 bits) y MATLAB R2013b, consulte aquí: mathworks.com/matlabcentral/newsreader/view_thread/332791 . ¡Hasta ahora, no hay solución viable!
Michal

11
Gracias por los (10) * unos (10); en el archivo startup.m: resolvió mi problema por el momento. Por cierto, este error es simplemente increíble ...
Danduk82

Recibo este error con mis propios archivos mex (compilados con gfortran). ¿Hay alguna forma de que pueda construirlos de manera diferente para evitar este problema? Los indicadores incluyen -fPIC que, según los documentos, debería usar TLS global-dynamic en lugar de initial-exec.
robince

Confirmo este problema en Ubuntu 12.04 64bit. Y reemplazar la biblioteca con la del informe de errores resolvió el problema. +1
NKN

27

Reiniciar Matlab resolvió el problema por mí.


He visto un comportamiento similar. Después del primer inicio, matlab emite el mensaje de error anterior. Después de reiniciar, el error no vuelve a aparecer. El error vuelve a aparecer después de un segundo reinicio, y esto se puede repetir una y otra vez. Reaparece de forma intermitente después del primer, tercero, quinto, ... inicio de matlab.
Christoph

1
Para mí también resolvió mi problema. Pero agradecemos a user2898218 por compartir todo eso.
desmond13

No funcionó para mí en OpenSuse Leap 42.1 con Matlab R2016b
Sameer

6

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á.


¡Funciona bien para mí! ¡Gracias!
user2230101

5

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

  1. 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


esta fue una solución para mí en un entorno completamente diferente: issues.dlang.org/show_bug.cgi?id=17061
timotheecour

¡Gracias! la única solución que funcionó para mí (y la más simple). Estoy usando algunas bibliotecas externas sin código fuente. Lo más divertido es que el problema aún existe en Matlab 2016b ...
foxfireee

4

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.


1
Por favor, publique la solución también, ya que el enlace puede volverse inactivo en cualquier momento.
Lakshmi

la solución es un archivo adjunto a la licencia de MathWorks. No podemos redistribuirlo y lo construyeron ellos mismos, por lo que no hay forma de "publicar la solución". Aparte de eso, no me funciona: debería arreglarse para R2014b, pero sigo recibiendo el error.
oveja voladora

3

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í!


¿Qué vínculos crea esto? Vinculé manualmente todos los scripts sin la extensión .sh allí y el error todavía está presente.
oveja voladora

3

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.


Tiene el mismo problema al cargar libmwosgserver.so en Matlab 2014a. Pero funcionó cuando bajé a Matlab 2013b.
Temak

2

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.


0

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


0

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.