Press "Enter" to skip to content

Post-mortem debugging – O que é isso?

Depurar código faz parte do nosso dia a dia. Adoramos nossas IDEs cheias de recursos e janelas que facilitam nosso trabalho. Adicionamos nossos breakpoints e vamos navegando pelos códigos tentando entender a origem de um determinado problema.

Apesar das facilidades das IDEs, e do ambiente controlado (nem sempre) do nosso ambiente de trabalho, depurar nem sempre é uma tarefa fácil. Mas mesmo com as dificuldades, na maioria das vezes ainda estamos no controle. Temos a possibilidade de analisar, voltar, recomeçar e entender o problema.

Mas o que fazemos quando o sistema para em produção? E ele para! E você vai ver os logs da aplicação descobre que está tudo ok, pelo menos segundo os logs :(.

É ai que entra o tal de post-mortem debugging.

Além de um nome legal, post-mortem debugging é a depuração de uma aplicação depois que ela deu problema. E o que usamos para identificar o problema? Só um dump de memória da aplicação.

O que é um dump, como criar, quais ferramentas vamos utilizar? Nós próximos posts vamos avançando com calma nesses assuntos. Mas já adianto que vamos passar longe do Visual Studio :). Afinal caso precise depurar no ambiente do cliente não vai pedir para ele instalar o Visual Studio, certo? 😉

Antes de finalizar vamos ver um exemplo real onde post-mortem debugging foi útil.

O que a mensagem de erro abaixo diz para você?

ORA-01017: invalid username/password; logon denied

Qual o problema com a aplicação que apresentou essa mensagem? O que você faria?

Apesar de parecer simples, nunca é simples. Só alguns computadores apresentavam esse problema, e todos usavam a mesma string de conexão. Reproduzir localmente? Esquece! Só acontecia no cliente.

O problema real? Bem diferente do que a ODP.NET da Oracle mostrava nesse ORA-01017. Veja abaixo a stack do problema.

odpnet

Nada como devolver uma exception que esconde o real problema hein? 😀

Até o próximo post onde vamos ver o que é e como criar memory dumps.

  • Diogo Damiani Ferreira

    Boa Márcio! WinDbg salva por aqui muitas vezes também!

    • Valeu :). Pois é acho que é algo que todos precisam ter um conhecimento básico pelo menos. Em momentos de desespero ele é sempre útil hehe. Na verdade as vezes uso ele para ver processos rodando no lugar do Visual Studio, para algumas coisas é mais prático.

  • Ótimo artigo.
    Já estou curioso pelos próximos, realmente uma exception em produção é caso sério, e dá trabalho identificar sem boas técnicas.

  • Zoio Silva

    Muito interessante. Nunca cheguei a precisar, mas é imprescindível conhecer. Chegou minha hora!

  • Pingback: Post-mortem debugging – Dumps de memória | Márcio Althmann()