Simbolización de fallos en juegos: asociar los informes con la compilación exacta que se distribuyó

Propósito

Un informe de fallo que contiene direcciones es solo el comienzo de una investigación. La simbolización asocia ubicaciones de código con funciones y, cuando existe la información necesaria, con líneas de código fuente. Esa asociación depende del binario exacto que se ejecutó. Conservar los símbolos de una versión cercana o recompilar más tarde el mismo código fuente no demuestra que el archivo de símbolos corresponda al ejecutable del jugador. Trata los archivos ejecutables, los símbolos y la identidad del código fuente como un único registro de versión.

Cómo funciona

Un volcado (dump) captura una selección del estado del proceso en un momento determinado. Su contenido depende de cómo se haya creado; un volcado pequeño no garantiza incluir datos arbitrarios del heap. Microsoft documenta que se necesitan archivos ejecutables y de símbolos que coincidan, y que hay información adicional de memoria disponible en los volcados que incluyen el heap. Un depurador no puede, sin más, reanudar un volcado capturado como si fuera el juego en ejecución.

La información de símbolos puede describir funciones, variables y correspondencias de líneas. Aun así, la pila visible es evidencia de un fallo observado, no prueba de la causa original. Un acceso inválido puede ser la consecuencia tardía de un objeto obsoleto o de una corrupción anterior.

Ejemplo práctico

Supongamos que un estudio distribuye las compilaciones B17 y B18. Sus ejecutables tienen el mismo nombre de archivo, Game.exe, pero la disposición de su código es distinta. Un informe de B17 debe resolverse con el ejecutable de esa compilación y su Game.pdb; no basta con elegir por nombre de archivo los símbolos de B18.

Almacena cada versión bajo una identidad de compilación inmutable y usa las comprobaciones de coincidencia de módulos y símbolos del depurador. Si faltan los símbolos exactos, registra esa limitación en lugar de presentar como verificado el nombre de una función que solo es plausible. Estas etiquetas de compilación son un ejemplo ilustrativo, no registros de un fallo real.

Flujo de trabajo práctico

Durante la compilación, conserva juntos el ejecutable, las bibliotecas relevantes, los símbolos correspondientes y la revisión del código fuente. Prueba la ruta de reporte provocando un fallo deliberado en una compilación controlada. Confirma que se reconoce el módulo capturado y que los frames esperados se resuelven con los artefactos conservados.

Cuando llegue un informe, revisa su configuración de compilación, la categoría de la excepción, el hilo que falló y otros hilos relevantes. Adjunta un contexto conciso del estado del juego que ayude a reproducir la situación. El sistema de reportes de Unreal admite contexto personalizado y puede distinguir entre fallos, aserciones y ensures no fatales; no agrupes estas categorías como si fueran fallos idénticos. Verifica por separado la configuración de reportes del juego empaquetado y la del editor.

Límites y verificación

La optimización y el inlining pueden hacer que la inspección a nivel de código fuente sea incompleta, y que falte una variable no demuestra que tuviera un valor concreto. Agrupa los informes relacionados con información estable que tenga en cuenta la compilación y compara el contexto circundante antes de declarar una única causa raíz.

El contenido de los volcados y los registros puede incluir memoria de la aplicación o información proporcionada por el usuario, así que elige con cuidado los campos que se recopilan y quién tiene acceso. Conserva los artefactos necesarios para las versiones que siguen recibiendo soporte. Tras corregir una causa sospechada, reproduce el escenario original y añade una comprobación de regresión específica; una pila simbolizada, por sí sola, no demuestra que el defecto esté resuelto.

Fuentes

• Use dump files in the debugger — Microsoft
• Symbols and Symbol Files — Microsoft
• Crash Reporting in Unreal Engine — Epic Games