Parte 3.3: depuradores, volcados de núcleo y recopilación de volcados de núcleo

Se aplica a:   .NET Core 2.1, .NET Core 3.1, .NET 5

En este artículo se presentan los depuradores y volcados principales y las herramientas para capturar y analizar los archivos de volcado de datos principales en Linux.

Requisitos previos

Al igual que en las partes anteriores,esta parte está estructurada para poner más énfasis en la teoría y los principios a seguir cuando empiece a solucionar problemas. No tiene requisitos previos. Sin embargo, debes tener los siguientes elementos ya configurados si has seguido todos los pasos de este aprendizaje hasta ahora:

• Nginx tiene dos sitios web:
  • El primer sitio web escucha las solicitudes mediante el encabezado de host myfirstwebsite ( ) y enruta las solicitudes ASP.NET Core la aplicación de demostración que escucha en el puerto http://myfirstwebsite 5000.
  • El segundo sitio web escucha las solicitudes mediante el encabezado host buggyamb ( ) y enruta las solicitudes ASP.NET Core la segunda aplicación de ejemplo de errores que escucha en el puerto http://buggyamb 5001.
• Ambas ASP.NET Core se ejecutan como servicios que se reinician automáticamente cuando se reinicia el servidor o las aplicaciones deja de responder o se produce un error.
• Un firewall local de Linux está habilitado y configurado para permitir el tráfico SSH y HTTP.

Objetivo de esta parte

En esta parte se presenta el concepto de volcados y depuradores principales, así como las herramientas que puede usar para capturar y analizar los archivos de volcado de datos principales. La mayoría de las técnicas y herramientas que se describen en esta parte se usarán en los siguientes laboratorios de solución de problemas.

Volcado de núcleo

Al igual que un volcado de memoria en modo de Windows, un volcado de memoria principal es una instantánea de la memoria de un proceso. Con frecuencia, se necesitan volcados principales para solucionar problemas de rendimiento en Linux.

Un depurador (colección manual de volcados) puede generar un volcado principal a petición o puede configurarse para que se recopila automáticamente después de un error del proceso.

¿Qué sucede cuando se produce un error en un proceso en Linux?

La mayoría de los sistemas Linux tienen volcados principales habilitados de forma predeterminada. El sistema genera un volcado de memoria para cualquier proceso que se termine inesperadamente. Esto es similar a la manera en que Informe de errores de Windows (WER) genera volcados para procesos que terminan de forma anormal.

Estos son algunos aspectos clave de cómo se comporta un sistema Linux relacionado con la generación de archivos de volcado de datos principales:

• De forma predeterminada, se genera un archivo de volcado de memoria cuando un proceso finaliza inesperadamente.
• El archivo de volcado principal se denomina "core" y se crea en el directorio de trabajo actual o en el /var/lib/systemd/coredump directorio.
• Aunque el comportamiento predeterminado es que el sistema operativo genere un archivo de volcado de memoria, esta configuración se puede sobrescribir para canalizar directamente el resultado del archivo de volcado de memoria a /proc/sys/kernel/core_pattern otra aplicación.

Estas opciones predeterminadas y otras, como los límites de tamaño, se pueden establecer en los archivos de configuración. Los siguientes recursos profundizan más en este tema:

• Volcados principales

• Vínculo externo: núcleo de página man de Ubuntu: archivo de volcado de datos principal

Apport: la forma de Ubuntu de administrar volcados principales

En Ubuntu, el servicio del sistema apport administra la generación de volcado de datos principales. Incluso si la generación de volcados principales del sistema operativo está deshabilitada, apport seguirá creando archivos de volcado de memoria.

Apport usa /proc/sys/kernel/core_pattern para canalizar directamente el archivo de volcado de memoria a apport. Si ejecuta el comando mientras se ejecuta cat /proc/sys/kernel/core_pattern apport, debería ver el siguiente resultado.

Si deshabilita apport, esto no impedirá la generación de volcados principales al finalizar el proceso. En su lugar, simplemente detiene apport. A continuación, el sistema revertirá a su comportamiento predeterminado generando los propios volcados de núcleo. Si ejecuta lo mismo después cat /proc/sys/kernel/core_pattern de detener apport, verá el siguiente comportamiento predeterminado del sistema.

Deshabilitar la generación automática de volcado de memoria

Para deshabilitar la generación automática de archivos de volcado de memoria, siga estos pasos:

1. Detenga y deshabilite apport.
2. Deshabilite la acción predeterminada del sistema.

Apport se puede detener y deshabilitar igual que cualquier otro servicio. Use el sudo systemctl stop apport comando y el comando para detener el servicio y, a continuación, deshabilite sudo systemctl disable apport para evitar que se reinicie.

Para deshabilitar la generación automática de archivos de volcado del sistema operativo para todos los procesos que se ejecutan en todas las cuentas de usuario del equipo, debe seguir los pasos que se proporcionan en artículos como este .

Capturar el volcado de memoria y los depuradores

Hay varias herramientas disponibles para capturar un archivo de volcado de datos principal, como gcore, gdb y varias herramientas para analizar un archivo de volcado de memoria, como objdump, kdump, gdby lldb.

Sin embargo, encontrará algunas dificultades importantes al trabajar con estas herramientas para intentar realizar la depuración de .NET:

• La configuración puede ser difícil en comparación con el proceso de configuración de símbolos para el depurador de WinDbg en Windows.
• Los archivos de volcado de datos principales son grandes porque estas herramientas no saben qué región de memoria se usa en un proceso de .NET Core y no pueden recortar la información de memoria solo en lo que se necesita.
• Los archivos de volcado no son portátiles. Tendrás que analizar los archivos de volcado en el equipo Linux en el que se generaron. Si desea analizar los archivos de volcado en diferentes equipos Linux, es necesario realizar pasos adicionales para configurar el equipo host para la sesión de depuración.

lldb

Lldb es la herramienta recomendada para analizar el volcado de .NET Core. El SDK de .NET incluye herramientas útiles para configurar lldb correctamente. Sin embargo, debe instalar al menos la versión 3.9 para poder realizar dicho análisis de depuración para .NET Core.

Para instalar lldb 3.9 o una versión posterior, use Administrador de paquetes (por ejemplo: sudo apt install lldb ).

Herramientas y comandos disponibles en el SDK y tiempo de ejecución de .NET Core

Se incluyen varias herramientas útiles junto con el tiempo de ejecución de .NET Core. Por ejemplo, createdump se instala como parte de cada instalación en tiempo de ejecución de .NET Core.

También puede desarrollar sus propias herramientas o elegir usar varias herramientas de terceros. La plataforma microsoft .NET Core también incluye algunas herramientas de .NET Core que son útiles para depurar problemas de .NET Core. Entre ellas se incluyen las siguientes:

• dotnet-dump
• dotnet-gcdump
• dotnet-symbol

Para instalar estas herramientas junto con las demás, debe tener instalado el SDK de .NET Core. Para obtener más información acerca del SDK de .NET Core, vea: Introducción al SDK de .NET.

Nota

Procdump también es digno de una mención, aunque no forma parte del SDK. Al final de esta parte se puede encontrar una explicación detallada de las opciones de ProcDump.

createdump

Createdump se instala en todas las versiones de .NET Core. Para obtener más información, vea los detalles de implementación.

Createdump es la mejor manera de generar un archivo de volcado de memoria en Linux. Esto se debe a que es posible que los archivos de volcado generados automáticamente por el sistema no incluyan todos los estados administrados. Además, algunos comandos SOS o dotnet-dump pueden mostrar "UNKNOWN" para los nombres de tipo y función.

Del mismo modo, los archivos de volcado manual que se crean mediante gdb o gcore no incluirán toda la información de estado administrado, y algunos comandos SOS o dotnet-dump también pueden mostrar "UNKNOWN" para los nombres de tipo y función. La forma recomendable de capturar archivos de volcado manual es mediante createdump o alguna otra herramienta de .NET Core, como procdump.

Estas son algunas características importantes de createdump:

• Los minidumps de tamaño mínimo se generan automáticamente.
• Es fácil de configurar con un usuario que no es raíz.
• Puede usarlo para capturar archivos de volcado de memoria a petición (manual) o de error del sistema.
• Se detectan la mayoría de los errores de desbordamiento de la pila.

Debe usar lldb 3.9 o una versión posterior para analizar los archivos de volcado principales que se capturan mediante createdump.

Puede encontrar createdump en el directorio de instalación de .NET Core. Para buscar este directorio, ejecute el dotnet --list-runtimes comando. Como se muestra en la siguiente captura de pantalla, se creó un archivo createdump independiente para las dos versiones de los tiempos de ejecución activos.

dotnet-dump

Debe tener instalado .NET Core SDK para poder instalar esta herramienta. Dotnet-dump se introdujo en el SDK de .NET Core 3.0. Ayuda a recopilar y analizar archivos de volcado de datos principales sin necesidad de ningún depurador nativo. Le permite ejecutar comandos SOS para analizar errores y salida del recolector de elementos no utilizados (GC).

Nota

Dotnet-dump no es un depurador nativo. Por lo tanto, algunas características, como mostrar los marcos de pila nativos, no están disponibles. El archivo de volcado que se genera no es portátil y no se puede abrir en Windows.

Para instalar esta herramienta, ejecute el siguiente comando:

dotnet tool install -g dotnet-dump

Usará esta herramienta para capturar y analizar los archivos de volcado principales en las próximas secciones del laboratorio.

dotnet-gcdump

Esta es otra herramienta que requiere .NET Core SDK. Dotnet-gcdump está disponible en .NET Core 3.1 o versiones posteriores.

Este es un enfoque interesante para analizar los montón de GC. La idea detrás de esta herramienta es que un archivo de volcado de proceso completo no es necesario para las investigaciones en muchos escenarios. Por lo tanto, la herramienta captura solo la información del montón administrado y genera un informe basado en ella.

Lo más importante es que los archivos de volcado generados por esta herramienta son portátiles y se pueden analizar en PerfView o Visual Studio en Windows.

Como se explica brevemente aquí,esta herramienta desencadena una recolección completa de elementos no utilizados para transmitir la información a una "canalización de eventos" para generar el archivo de volcado.

Nota

Dado que se desencadena una recolección completa de elementos no utilizados de gen 2 en el proceso de destino, se pueden cambiar las características de rendimiento de la aplicación. Como es de esperar, mientras la información se escribe en el archivo de volcado de datos principal, los subprocesos se suspenderán. Cuanto mayor sea el tamaño del montón, más largas serán las pausas para escribir la información en el archivo y más tiempo permanecerán en pausa los subprocesos.

La información contenida dentro de estos archivos de volcado de datos principales será útil en las siguientes circunstancias:

• Comparar el número de objetos por tipo en el montón administrado
• Análisis de raíces de objetos
• Determinar qué objetos tienen una referencia a qué tipo
• Otro análisis estadístico sobre objetos en el montón

Una vez generados los datos, el archivo se puede exportar fuera del equipo en el que se creó y se puede analizar en PerfView o en Visual Studio.

Para instalar esta herramienta, ejecute el siguiente comando:

dotnet tool install -g dotnet-gcdump

Usará este comando para generar algunos informes para los montón de .NET Core en las próximas secciones de laboratorio.

dotnet-symbol

Dotnet-symbol es una herramienta útil para obtener símbolos para la depuración administrada. Se introdujo en .NET Core 2.1. En cuanto a las otras dos herramientas mencionadas anteriormente, estas herramientas también requieren que se instale .NET Core SDK.

Dotnet-symbol descarga todos los archivos necesarios para la depuración (símbolos, módulos, SOS y DAC para el módulo coreclr) para los archivos de volcado de núcleo determinados.

Para instalar esta herramienta, ejecute el siguiente comando:

dotnet tool install -g dotnet-symbol

Usará esta herramienta para configurar el depurador en las próximas secciones de laboratorio.

procdump

También está disponible una versión de Linux de ProcDump. Tiene algunos conjuntos de características limitados en comparación con su Windows equivalente. No admite todas las características que hace Windows versión. Por ejemplo, no se puede configurar para recopilar archivos de volcado de datos principales cuando el proceso se bloquea o produce una excepción de primera oportunidad. Sin embargo, sigue siendo una herramienta eficaz.

Las siguientes opciones de línea de comandos para ProcDump desencadenan la generación de archivos de volcado principales en las condiciones especificadas.

-C: CPU exceeds or equals a specified value (0 to 100 * nCPU)
-c: CPU is less than a specified value (0 to 100 * nCPU)
-M: The memory commit exceeds or equals a specified value (MB)
-m: The memory commit is less than a specified value (MB)
-T: The thread count exceeds or equals a specified value
-F: The filedescriptor count exceeds or equals a specified value

Siga las instrucciones de instalación para instalar ProcDump en su entorno.

Usará esta herramienta para capturar un archivo de volcado de memoria basado en el uso de CPU en las próximas secciones del laboratorio.

Una nota sobre cómo seleccionar la versión del SDK

De forma predeterminada, el SDK se instala en una configuración "en paralelo". Esto significa que varias versiones pueden ejecutarse juntas en un solo equipo. El modo en que se elige la versión al ejecutar comandos de la CLI se explica con más detalle en el artículo Seleccionar la versión de .NET Core para usar. Sin embargo, el proceso para seleccionar una versión de SDK se puede resumir de la siguiente manera:

• .NET Core busca un archivo global.json invertidamente navegando por la ruta hacia arriba desde el directorio de trabajo actual.
• .NET Core usa el SDK especificado en el primer global.json que se encuentra.
• .NET Core usa el SDK instalado más reciente si no se encuentra ninguna instancia global.json.

Por ejemplo, en la máquina virtual Linux de prueba, debe tener instalados los SDK de .NET Core 3.1 y 5.0. Si ejecuta .NET Core mediante la inclusión del modificador, debería ver que se usa --version la versión más reciente.

Ahora, cree un archivo global.json en el directorio actual (su directorio principal) y establezca la versión explícitamente mediante la herramienta cat, como se muestra. A continuación, compruebe la versión de nuevo. Ahora se muestra la versión exacta del SDK que se coloca dentro del archivo global.json.

Esto es importante saber al ejecutar algunos comandos de SDK, como crear una aplicación mediante el comando .NET new Core. Sin embargo, no tendrá que hacerlo cuando use las herramientas dotnet-dump y dotnet-gcdump.

.NET Core SDK instala la versión más reciente de las herramientas independientemente del SDK que haya seleccionado. Por ejemplo, si ejecutó los comandos para instalar las herramientas dotnet-dump, dotnet-gcdump y dotnet-symbol para .NET Core SDK 3.1, se descargarán e instalarán las versiones más recientes de estas herramientas, como se muestra en la siguiente captura de pantalla (donde se ha instalado la versión 5 de las herramientas para dotnet-dump y dotnet-gcdump).

Los artículos siguientes son excelentes recursos para obtener más información sobre las herramientas de .NET Core:

• Cómo administrar herramientas de .NET

• instalación de la herramienta dotnet

Nota

Seleccionar la versión en tiempo de ejecución que se va a usar es diferente de seleccionar la versión del SDK. Si desea usar una versión específica del tiempo de ejecución de .NET, use la opción <VERSION> --fx-version, como se explica en este artículo.

Siguientes pasos

Ya está listo para comenzar los laboratorios de solución de problemas. En los laboratorios, aprenderás a usar las herramientas que se debate aquí para solucionar problemas.

Laboratorio 1.1 Reproducir y solucionar un problema de bloqueo