Como corrijo um bug “emergente”?

5

Estou escrevendo um solucionador de PDE e tenho um bug que só aparece em casos de teste muito grandes. Isto é, com pequenas redes, o programa dá respostas corretas, mas há uma grande quantidade de erro não contabilizado (eu respondi por arredondamento, discretização e outros tipos de erros padrão que inevitavelmente ocorrem) que se arrasta quando meus casos de teste se tornam no intervalo de dias a terminar.

Não posso executar isso em um depurador, isso levaria semanas. E imprimir resultados intermediários não é particularmente útil, pois não posso inspecionar manualmente a saída para ver o que está errado.

Como posso encontrar e corrigir esse bug "emergente"?

    
por Dan 10.07.2014 / 22:56
fonte

3 respostas

2

Primeiro, resista ao fato de que isso provavelmente levará um tempo longo para ser resolvido. Eu tive um bug há alguns anos que levou quase um ano para ser consertado, porque era muito demorado para se reproduzir.

Uma dica é garantir que seu código seja compilado sem avisos e passe na análise estática. Obter uma revisão por pares também. Você pode ter algo como uma condição de corrida com uma chance de 0,001% de ocorrer. As ferramentas de análise estática podem ajudá-lo a encontrar esses tipos de erros.

Verifique se seu código está super limpo. Elimine all a repetição e torne suas funções pequenas. Tire todas e quaisquer otimizações que você possa ter feito, e substitua-o por um código que seja tão simples de ler, que todos os bugs aparecerão como um polegar dolorido. Somente após o seu código funcionar você deve colocar as otimizações de volta, uma a uma, com um teste entre cada uma. O código mais difícil para você ler é o código com maior probabilidade de conter um bug.

Escreva uma tonelada de testes unitários, que cubram todos os casos de limite do seu erro explicado. O cenário mais provável é que você acidentalmente cometeu um erro com um deles.

A próxima coisa que você pode fazer é escrever algum código extra para ajudá-lo a detectar e restringir o bug. Carregue com asserções e entradas de log. Automatize a detecção do bug em seus resultados intermediários, talvez comparando-o com um algoritmo mais lento, porém mais confiável. Escreva o código para verificar as condições que devem ser impossíveis de atingir e defina um ponto de interrupção, se necessário. Tornar possível salvar e reiniciar seu algoritmo a partir de um estado intermediário.

Outra técnica interessante que recentemente demonstrei ter um grande efeito em esta excelente palestra TED é criar uma visualização. O cérebro humano pode encontrar padrões e anomalias muito mais facilmente na forma visual.

Vou enfatizar novamente a necessidade de ser paciente. Se você tentar se apressar e tentar tomar atalhos, provavelmente levará mais tempo. Não tenha medo de fazer grandes mudanças com o único propósito de depuração. Você não desperdiçará seu esforço anterior, é para isso que o controle de código-fonte serve.

    
por 11.07.2014 / 00:04
fonte
8

Algumas sugestões:

  1. Uma coisa que você pode fazer é tentar diminuir o problema através da bissecção geométrica . (Eu usei isso com bastante sucesso na investigação de falhas de regeneração de CAD para recursos geométricos extremamente complexos.) A idéia aqui é cortar o modelo com falha pela metade, depois ver se o problema se reproduz em cada metade. Ao fazer isso, você poderá restringir um volume específico de seu modelo que faz com que seu solucionador fique fora de controle.

  2. Em segundo lugar, a maioria dos depuradores pode anexar a um processo já em execução. Se você puder de alguma forma adicionar um teste ao seu solucionador para detectar quando os erros estão começando a sair do controle (este teste pode ser codificado para o modelo e simulação específicos que apresentam o problema), o código de teste pode pausar a execução (colocando um "problema encontrado, pressione OK" caixa de diálogo se nada mais), e você pode anexar o depurador para ver o que aconteceu.

  3. De forma semelhante, você pode criar um caso de teste tão matematicamente trivial que seja analiticamente solucionável e executar esse caso de teste em uma grade muito grande? Você pode ver como os erros se acumulam, desde que você saiba a resposta correta com antecedência.

  4. É parte do problema aqui que sua estação de trabalho é lenta e um pouco obsoleta? Talvez você consiga convencer seu gerenciamento de que seu hardware precisa ser atualizado para permitir a depuração de simulações realistas de clientes.

por 10.07.2014 / 23:32
fonte
0

Examine um caso de teste de aprovação que se assemelhe à situação de falha. Então olhe para o que eles fazem diferente. Talvez até mesmo modifique o teste de aprovação, para que ele fique mais próximo do comportamento do teste com falha. Se de repente começar a falhar, você saberá onde começar a procurar.

    
por 10.07.2014 / 23:10
fonte

Tags