Bloqueos de solución de problemas del laboratorio 1.2: analizar los archivos de volcado de datos principales generados por el sistema en el depurador de lldb
Se aplica a: .NET Core 2.1, .NET Core 3.1, .NET 5
En este artículo se describe cómo instalar y configurar el depurador lldb en Linux y, a continuación, abrir y analizar los archivos de volcado de .NET Core generados por el sistema.
Requisitos previos
El requisito mínimo para seguir estos laboratorios de solución de problemas es tener una aplicación ASP.NET Core para demostrar problemas de bajo rendimiento de CPU y CPU alta.
Puede encontrar varias aplicaciones de ejemplo para lograr este objetivo en Internet. Por ejemplo, puede descargar y configurar el ejemplo de webapi simple de Microsoft para demostrar un comportamiento no deseado. O bien, puede usar la aplicación ASP.NET Core BuggyAmb como proyecto de ejemplo.
Si ha seguido las partes anteriores de esta serie, debe tener lista la siguiente configuración:
- Nginx está configurado para hospedar dos sitios web:
- El primero escucha las solicitudes mediante el encabezado de host myfirstwebsite ( ) y las solicitudes de enrutamiento a la aplicación de demostración ASP.NET Core que escucha en el puerto
http://myfirstwebsite5000. - El segundo escucha las solicitudes mediante el encabezado de host de buggyamb ( ) y las solicitudes de enrutamiento ASP.NET Core la segunda aplicación de ejemplo de errores que escucha en el puerto
http://buggyamb5001.
- El primero escucha las solicitudes mediante el encabezado de host myfirstwebsite ( ) y las solicitudes de enrutamiento a la aplicación de demostración ASP.NET Core que escucha en el puerto
- Ambas ASP.NET Core deben ejecutarse como servicios que se reinician automáticamente cuando se reinicia el servidor o la aplicación deja de responder.
- El firewall local de Linux está habilitado y configurado para permitir el tráfico SSH y HTTP.
Nota
Si la configuración no está lista, vaya a "Part 2 Create and run ASP.NET Core apps."
Para continuar con este laboratorio, debe tener al menos una aplicación ASP.NET Core web problemática que se ejecute detrás de Nginx.
Objetivo de este laboratorio
Este artículo es el segundo de dos partes de laboratorio para depurar bloqueos de ASP.NET Core aplicaciones en Linux.
En Laboratorio 1.1 Reproduciry solucionar un problema de bloqueo, siguió los pasos para reproducir un problema de bloqueo y inició la solución de problemas. Ha comprobado Nginx y los registros del sistema y ha procedido a solucionar problemas recopilando y analizando un archivo de volcado de memoria. Extrajo el archivo de volcado de núcleo de bloqueo que generó apport, el administrador de archivos de volcado principal de Ubuntu.
En esta parte, instalará y configurará el depurador de lldb para que funcione junto con la extensión del depurador de .NET Core denominada SOS y, a continuación, abra el archivo de volcado en lldb para analizarlo.
Instalar lldb
Para este laboratorio, debe instalar lldb 3.9 o una versión posterior. Las instrucciones para varias distros de Linux se detallan en Installing LLDB on Linux. Para esta sección, se recomienda usar el apt comando install: sudo apt install lldb . En la siguiente captura de pantalla, puede ver que lldb-6.0 está instalado junto con algunas dependencias.
Una vez finalizada la instalación, debe configurar lldb para que pueda cargar SOS automáticamente cuando se abra un archivo de volcado de memoria.
Configurar lldb
Antes de abrir el archivo de volcado de datos principal en lldb, siga estos pasos necesarios para establecer la ruta de acceso del símbolo, descargar los símbolos y cargar el SOS automáticamente cuando se abra lldb:
Instale la herramienta dotnet-symbol:
dotnet tool install -g dotnet-symbolDescargue los símbolos del archivo de volcado de destino:
dotnet-symbol <path_of_dump_file>Instalar SOS:
Instale la herramienta global dotnet-sos:
dotnet tool install -g dotnet-sosInstalar SOS:
dotnet-sos install
Instalar la herramienta dotnet-symbol
Ya debería haber instalado la herramienta dotnet-symbol junto con las herramientas dotnet-dump y dotnet-gcdump en la parte anterior. Si aún no ha instalado estas herramientas, instáleslas antes de continuar. Para ello, ejecute el dotnet tool install -g dotnet-symbol comando para instalar dotnet-symbols. Instale dotnet-dump y dotnet-gcdump, si aún no lo ha hecho. Ahora debes tener tres herramientas instaladas, como se muestra en la siguiente captura de pantalla.
Descargar símbolos para el archivo de volcado
En la parte 1,se le indicó cómo desempaquetar el archivo de volcado principal del informe de apport. Ahora es el momento de descargar los archivos de símbolos. Como se explica en este artículo,los símbolos funcionan en un nivel alto. Sirven como asignaciones entre el código fuente y los archivos binarios. Estas asignaciones las usan los depuradores para resolver los nombres de función o método, la información de línea de origen o los nombres de variables locales cuando leen una pila de llamadas.
Usará el comando para descargar los símbolos del archivo de volcado dotnet-symbol ~/dumps/dotnet/CoreDump -o ~/dumps/symbols --host-only de memoria en el ~/dumps/symbols directorio.
Puede recibir varios mensajes de error de "HTTP 404 no encontrado" al descargar archivos de símbolos si no agrega el --host-only modificador. Puede omitir estos mensajes de forma segura. El --host-only parámetro solo descargará el programa host. Esto es todo lo que lldb necesita para iniciar la depuración de la ASP.NET Core aplicación.
El siguiente paso es instalar la extensión de depuración administrada por SOS. Esto expondrá los comandos de depuración .NET necesarios para ejecutar el análisis.
Instalar SOS
¿Qué es SOS? De acuerdo con la documentación oficial,SOS es una extensión de depurador que permite a un desarrollador inspeccionar el estado administrado de una aplicación .NET, incluidos los ASP.NET Core y otros . Aplicaciones basadas en NET como .NET WPF y .NET Windows Forms. SOS es una extensión multiplataforma que puede cargar WinDbg o un depurador de cdb en Windows y lldb en Linux y macOS.
Para instalar SOS, primero debe instalar la siguiente herramienta dotnet-sos:
dotnet tool install -g dotnet-sos
A continuación, instale SOS:
dotnet-sos install
La siguiente captura de pantalla muestra el resultado de una instalación correcta. Observe que la herramienta dotnet-sos ha configurado el depurador lldb para que la extensión SOS se cargue automáticamente cuando se inicie el depurador.
Por último, está listo para abrir el archivo de volcado de datos mediante lldb.
Volcado de núcleo abierto en lldb
Para abrir el volcado de núcleo, debe usar lldb y la siguiente sintaxis:
lldb --core <dump path> <host-program>
Es <host-program> el programa nativo que inició la aplicación .NET Core. Normalmente se trata de dotnet, a menos que la aplicación sea independiente. Si se trata de una aplicación independiente, esta variable es el nombre de la aplicación sin la .dll extensión.
Suponiendo que sigue el procedimiento con los mismos nombres de carpeta, la ruta de acceso al archivo de volcado de memoria que generó en la sección anterior debe ser ~/dumps/dotnet/CoreDump. Por lo tanto, se ejecutará lldb --core ~/dumps/dotnet/CoreDump para abrir el archivo.
La siguiente captura de pantalla muestra el depurador lldb que ha abierto el archivo de volcado de memoria.
Establecer símbolos
Recuerde que descargó los archivos de símbolos mediante el dotnet-symbol comando del ~/dumps/symbols directorio. El primer comando que debe ejecutar dentro del depurador es establecer la ruta de acceso del servidor de símbolos en el directorio que establezca para las descargas de símbolos:
setsymbolserver -directory ~/dumps/symbols
Después, cargue los símbolos: loadsymbols
Ejecutar comandos lldb y SOS
Hay varios comandos lldb. Puede enumerar estos mediante el help comando. En la lista, puede ver que los comandos SOS también se enumeran en los comandos definidos por el usuario. SOS es un complemento para lldb. Puedes recuperar la información de ayuda del complemento con el mismo help comando.
Nota
Es posible que desee borrar el resultado de lldb de vez en cuando. Para ello, presione Ctrl+L.
Para empezar, vea la pila de llamadas nativas del subproceso mediante el bt comando ("seguimiento posterior"). Este comando muestra la pila de llamadas del subproceso activo.
A continuación, examine la pila de llamadas administradas mediante el comando clrstack SOS.
No debería poder recuperar ninguna información. Se producirá un error en el recorrido de la pila porque la pila notificada está incompleta. Esto está relacionado con lo que se ha comentado anteriormente: el archivo de volcado de núcleo generado automáticamente no puede recopilar todos los estados administrados.
Recuerde también que se produjo una excepción y esto hizo que el proceso se bloqueara. Echa un vistazo a la información de excepción ejecutando el comando pe SOS.
Como puede ver en el resultado, el comando muestra la información sobre la última excepción, si la hubiera, que se pe produjo en el subproceso actual.
El mensaje de excepción en este caso es recurso que no está disponible temporalmente. Sin embargo, el tipo de excepción y los nombres de función no se resuelven. En su lugar, sus valores se indican como desconocidos.
También se muestra la dirección de la excepción. Puede intentar pasar esta dirección como parámetro en el comando para ver pe si hay más detalles disponibles. A continuación, ejecute pe 00007F8244048538 .
Nota
En este comando, reemplace la dirección por la dirección que se muestra en el archivo de volcado.
Incluso si desea mostrar los objetos a los que se hace referencia en la pila, verá el mismo valor de unknown.
Puede intentar recuperar más información seleccionando una dirección de uno de los objetos de la pila y revisando el objeto mediante el dumpobj <address> comando.
Sin embargo, es probable que concluya que este comando también tendrá un efecto limitado porque devuelve solo mensajes más desconocidos. Es hora de dejar de trabajar con el archivo de volcado generado automáticamente. Ejecute el exit comando para finalizar la sesión de lldb.
En resumen, el archivo de volcado generado por el sistema le proporciona información, pero aún le falta información importante. En la siguiente parte, se le mostrará el enfoque recomendado para capturar un volcado de memoria.