Simbolização de crashes em jogos: associe os relatórios à build exata distribuída

Objetivo

Um relatório de crash com endereços é só o início de uma investigação. A simbolização associa locais do código a funções e, quando as informações necessárias existem, a linhas do código-fonte. Essa associação depende do binário exato que foi executado. Guardar os símbolos de uma release próxima ou recompilar o mesmo código-fonte mais tarde não comprova que o arquivo de símbolos corresponde ao executável do jogador. Trate executáveis, símbolos e identidade do código-fonte como um único registro de release.

Como funciona

Um dump captura parte do estado do processo em um determinado momento. Seu conteúdo depende de como foi criado; um dump pequeno não garante a presença de dados arbitrários do heap. A Microsoft documenta a necessidade de arquivos executáveis e de símbolos correspondentes, com informações adicionais de memória disponíveis em dumps que incluem o heap. Um depurador não consegue simplesmente retomar um dump capturado como se fosse o jogo em execução.

As informações de símbolos podem descrever funções, variáveis e mapeamentos de linhas. Ainda assim, a pilha visível é evidência de uma falha observada, não prova da causa original. Um acesso inválido pode ser a consequência tardia de um objeto obsoleto ou de uma corrupção anterior.

Exemplo prático

Suponha que um estúdio distribua as builds B17 e B18. Seus executáveis têm o mesmo nome de arquivo, Game.exe, mas a organização do código é diferente. Um relatório da B17 precisa ser resolvido com o executável e o Game.pdb dessa build; escolher os símbolos da B18 apenas pelo nome do arquivo não é suficiente.

Armazene cada release sob uma identidade de build imutável e use as verificações de correspondência de módulos e símbolos do depurador. Se os símbolos exatos estiverem ausentes, registre essa limitação em vez de apresentar como verificado um nome de função apenas plausível. Esses rótulos de build são um exemplo ilustrativo, não registros de um crash real.

Fluxo de trabalho prático

Durante o build, guarde juntos o executável, as bibliotecas relevantes, os símbolos correspondentes e a revisão do código-fonte. Teste o caminho de reporte provocando uma falha intencional em uma build controlada. Confirme que o módulo capturado é reconhecido e que os frames esperados são resolvidos com os artefatos guardados.

Quando um relatório chegar, examine a configuração da build, a categoria da exceção, a thread que falhou e outras threads relevantes. Anexe um contexto conciso do estado do jogo que ajude a reproduzir a situação. O sistema de reporte da Unreal permite contexto personalizado e consegue distinguir crashes, assertions e ensures não fatais; não agregue essas categorias como se fossem falhas idênticas. Verifique a configuração de reporte do jogo empacotado separadamente da do editor.

Limites e verificação

Otimização e inlining podem tornar incompleta a inspeção no nível do código-fonte, e uma variável ausente não é evidência de que ela tinha determinado valor. Agrupe relatórios relacionados usando informações estáveis que levem em conta a build e compare o contexto ao redor antes de declarar uma única causa raiz.

O conteúdo de dumps e logs pode incluir memória da aplicação ou informações fornecidas pelo usuário; por isso, escolha com cuidado os campos coletados e quem tem acesso a eles. Mantenha os artefatos necessários para as releases suportadas. Depois de corrigir uma suposta causa, reproduza o cenário original e adicione uma verificação de regressão específica; uma pilha simbolizada, por si só, não demonstra que o defeito foi resolvido.

Fontes

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