¿Qué es un minivolcado?

Bugsnag ha agregado recientemente soporte para el procesamiento de minivolcados para que los clientes puedan rastrear bloqueos nativos en Electron o bloqueos generados al usar Breakpad o Crashpad .

Agregar compatibilidad con minivolcado supuso una serie de desafíos técnicos que tuvimos que abordar para asegurarnos de poder procesar los archivos de manera eficiente y escalable sin afectar nuestro rendimiento normal de procesamiento de eventos de error.

¿Qué es un minivolcado?

Un minivolcado es un archivo que generan algunos procesos cuando fallan. Son más pequeños que los volcados del núcleo y solo proporcionan los datos necesarios para realizar operaciones básicas de depuración.

El formato de archivo de minivolcado se inventó para su uso en Windows cuando el sistema operativo encuentra un error inesperado. Posteriormente, herramientas como Breakpad y Crashpad de Google adoptaron el mismo formato para generar volcados de aplicaciones en múltiples plataformas. Las aplicaciones creadas con Electron también generan archivos de minivolcado para fallas nativas (ya que Electron usa Crashpad).

El archivo de minivolcado contiene información sobre el proceso en el momento del bloqueo e incluye detalles como:

• La razón del basurero.
• Una lista de los módulos (ejecutables y bibliotecas compartidas) que se cargaron en el proceso.
• Detalles de los subprocesos activos, incluidos los registros y el contenido de la pila para cada subproceso.
• Metadatos sobre el dispositivo (versión del sistema operativo, CPU, etc.).

Cómo obtener seguimientos de pila útiles de un minivolcado

Caminando la pila

Dentro del minivolcado hay una pila de tiempo de ejecución de cada subproceso activo (en el momento en que ocurrió el error) y los valores de registro para esos subprocesos.

Estos detalles se pueden usar para recorrer la pila y producir un seguimiento de la pila para cada subproceso. En algunos casos, es posible obtener un seguimiento de pila válido (aunque no simbolizado) usando solo este método, pero en otros casos necesitamos información adicional del marco de llamada (CFI) que se proporciona dentro de los archivos de depuración.

Información del marco de llamada

Los registros de información de marco de llamada (CFI) describen cómo restaurar los valores de registro en una dirección de máquina en particular. Estos datos generalmente se proporcionan en los archivos de depuración y permiten generar un seguimiento de pila más confiable al recorrer la pila.

Sin la información de CFI, es posible que el caminante de la pila deba escanear la pila para intentar encontrar el marco de llamada, pero esto puede ser menos confiable y puede producir seguimientos de pila no válidos.

Simbolizando la Tasa de Pila

Una vez que se haya obtenido un seguimiento de la pila, solo contendrá las direcciones de cada marco. Para producir un seguimiento de pila significativo (con el nombre de la función, el archivo de origen y el número de línea de origen para cada fotograma), necesitamos "simbolizarlo", es decir, aplicarles los símbolos de depuración.

El archivo de depuración relevante del compilador (por ejemplo, dSYMs para macOS) podría usarse para esto, pero Breakpad ha definido su propio formato de archivo de símbolos que se puede usar en su lugar.

El archivo de símbolos de Breakpad es más simple que la mayoría de los archivos de depuración generados por el compilador (no contiene detalles como el árbol de sintaxis abstracta), pero proporciona los detalles necesarios, en un formato legible, para simbolizar el seguimiento de la pila.

Herramientas Breakpad

Breakpad proporciona una serie de herramientas para ayudar a procesar manualmente un minivolcado o cargarlos en un servidor/servicio dedicado para su procesamiento:

• minidump_stackwalk Toma un archivo de minivolcado y archivos de símbolos Breakpad opcionales y genera el seguimiento de la pila para cada subproceso junto con otra información (como el motivo del bloqueo, valores de registro para cada marco, detalles del sistema operativo, etc.). Esta es una herramienta útil para analizar minivolcados y obtener seguimientos de pila significativos de ellos.

  
  

• minidump_dump Proporciona información más detallada sobre el minidump (como detalles de cada uno de los flujos dentro del minidump).

  
  

• minidump_upload Sube archivos de minivolcado a un servidor dedicado para su procesamiento (como Bugsnag).

  
  

• dump_syms Genera archivos de símbolos Breakpad a partir de los archivos binarios y de depuración de la aplicación.

  
  

• symupload Carga los archivos de símbolos de Breakpad en un servidor dedicado para su procesamiento (como Bugsnag).

  
  

A continuación se puede ver un ejemplo de la salida de la herramienta minidump_stackwalk con los archivos de símbolos relevantes:

-- CÓDIGO idioma-texto simple --Sistema operativo: Windows NT 10.0.19041 1151CPU: familia amd64 23 modelo 24 stepping 1 8 CPU

GPU: DESCONOCIDO

Motivo del bloqueo: excepción de C++ no controlada Dirección del bloqueo: 0x7ff887f54ed9Tiempo de actividad del proceso: 4 segundos

Subproceso 0 (bloqueado) 0 KERNELBASE.dll + 0x34ed9

rax = 0x655c67616e736775 rdx = 0x6f6d2d6576697461 rcx = 0x6e2d7070635c656d rbx = 0x00007ff87f731600 rsi = 0x000000b80f3fcb70 rdi = 0x000000b80f3fca40 rbp = 0x000000b80f3fca10 rsp = 0x000000b80f3fc8d0 r8 = 0xaaaaaaaa0065646f r9 = 0xaaaaaaaaaaaaaaaa r10 = 0xaaaaaaaaaaaaaaaa r11 = 0xaaaaaaaaaaaaaaaa r12 = 0x00007ff87f6f1ba0 r13 = 0x000010ff084af60d r14 = 0xffffffff00000000 r15 = 0x0000000000000420 rip = 0x00007ff887f54ed9 Found by: given as instruction pointer in context 1 KERNELBASE.dll + 0x34ed9 rbp = 0x000000b80f3fca10 rsp = 0x000000b80f3fc908 rip = 0x00007ff887f54ed9 Found by: stack scanning 2 ntdll.dll + 0x34a5f rbp = 0x000000b80f3fca10 rsp = 0x000000b80f3fc960 rip = 0x00007ff88a6a4a5f Found by: stack scanning 3 my_example.node!CxxThrowException [throw.cpp : 131 + 0x14] rbp = 0x000000b80f3fca10 rsp = 0x000000b80f3fc9b0 rip = 0x00007ff87f6fab75 Encontrado por: escaneo de pila 4 my_example.node!RunExample(Nan::FunctionCallback(Nan::FunctionCallback) nfo v8::Value const &) [my_example.cpp : 26 + 0x22] rbp = 0x000000b80f3fca10 rsp = 0x000000b80f3fca20 rip = 0x00007ff87f6f1ec2 Encontrado por: call frame info.. .

Desafíos técnicos del procesamiento de minivolcados

Enfrentamos algunos desafíos técnicos al agregar soporte de minivolcado a Bugsnag.

Los minivolcados varían bastante de nuestras cargas útiles JSON de eventos de error habituales, por lo que teníamos que asegurarnos de poder procesarlos de manera eficiente, resistente y escalable.

Tamaño del archivo

Los archivos de minivolcado pueden ser mucho más grandes que las cargas normales que recibimos; nuestras cargas útiles normales tienen un promedio de ~20 KB, mientras que los minivolcados suelen tener un tamaño de cientos de kilobytes. Además, los minivolcados pueden llegar a ser bastante grandes (decenas de megabytes) si hay muchos subprocesos activos o subprocesos con pilas grandes.

Normalmente, cuando recibimos cargas útiles de eventos de error, las agregamos a una cola de Kafka para el procesamiento asíncrono, de modo que podamos manejar cualquier retraso con las cargas.

Necesitábamos asegurarnos de que el mecanismo de cola fuera confiable si estábamos poniendo en cola archivos de minivolcado más grandes. Los archivos de minivolcado se comprimen bien (por lo general, alrededor del 10 % de su tamaño original), pero aún existía el riesgo de que los archivos comprimidos fueran demasiado grandes.

Hicimos algunas pruebas de carga con mensajes de varios tamaños en una instancia interna de Kafka y descubrimos que:

• El rendimiento de los datos y el retraso de la replicación no se vieron realmente afectados por el tamaño de los archivos.

• La cantidad de mensajes que podían procesarse por segundo disminuyó a medida que aumentaba el tamaño promedio del archivo.

  
  

Esta disminución del rendimiento de mensajes solo fue significativa cuando se pusieron en cola simultáneamente muchos archivos particularmente grandes, pero anticipamos que estos deberían ser muy raros y, por lo tanto, Kafka será adecuado para este propósito.

Velocidad de simbolización

Al simbolizar un minivolcado con la herramienta minidump_stackwalk de Breakpad, puede llevar mucho más tiempo procesar el minivolcado cuando se proporcionan los archivos de símbolos de Breakpad (debido al tiempo que lleva cargar los archivos de símbolos, analizarlos y buscar los datos de símbolos relevantes).

¡En un minivolcado de Electron de muestra, tomó 20 ms sin los archivos de símbolos Breakpad y 14 con ellos!

El tiempo de procesamiento más lento no es una gran preocupación cuando se simboliza manualmente un solo minivolcado, pero debemos asegurarnos de que podemos procesar y simbolizar minivolcados de la manera más eficiente posible para que podamos mantener un alto rendimiento de procesamiento de minivolcados.

Para lograr esto, implementamos nuestra propia lógica de simbolización. El formato de archivo de símbolos de Breakpad es simple y está bien documentado, lo que significa que podemos analizar el archivo para producir un archivo de mapeo personalizado que permita una fácil búsqueda de direcciones.

El archivo personalizado es mucho más grande que el archivo de símbolos Breakpad, pero también es mucho más eficiente para realizar las búsquedas. Hacer este procesamiento previo del archivo de símbolos de Breakpad significa que el tiempo necesario para procesar un minivolcado se reduce significativamente (a costa de mayores requisitos de almacenamiento para los archivos de símbolos).

Uso de la información del marco de llamada

En el diseño inicial del procesamiento de minivolcado, omitimos por completo el uso de archivos de símbolos Breakpad al recorrer la pila (para mejorar la eficiencia), pero pronto nos dimos cuenta de que esto a veces generaba seguimientos de pila no válidos debido a la falta de datos de Información de marco de llamada.

Sabíamos que si pasábamos los archivos completos de símbolos de Breakpad para el recorrido de la pila, sería lento (debido a que también intentaba simbolizar el seguimiento de la pila), así que optamos por producir una versión recortada del archivo que solo contenía el información necesaria para recorrer la pila.

Esto redujo en gran medida el tamaño del archivo de símbolos de Breakpad, así como el tiempo que llevó procesar el minivolcado, pero aun así no fue muy eficiente (tardó 1,5 s para un ejemplo de minivolcado de Electron).

Por lo tanto, exploramos la opción de serializar el archivo de símbolos Breakpad recortado para que pudiera leerse de manera más eficiente (en lugar de tener que analizar el archivo cada vez). El uso de una versión serializada del archivo redujo el tiempo de procesamiento de 1,5 s a 200 ms.

Esta mejora del rendimiento significa que deberíamos ser capaces de admitir un mayor rendimiento de minivolcados por instancia del servicio, lo que significa que podemos mantener bajos los costos de infraestructura.

Próximos pasos

A medida que crezca la adopción de la nueva característica, monitorearemos de cerca el uso de nuestra infraestructura para asegurarnos de continuar procesando los minivolcados de manera eficiente y ver si se deben realizar otras mejoras de rendimiento.

Bugsnag lo ayuda a priorizar y corregir errores de software mientras mejora la estabilidad de su aplicación.

Solicite una demostración