Depurando um processo lento [fechado]

5

Eu tenho um caso em que um bug demora mais de uma hora para se manifestar no modo de depuração (e ainda 20 min no modo de liberação). Alguém conhece uma estratégia de depuração que pode ajudar a reduzir o tempo de espera até que um ponto de interrupção seja alcançado na área do código que se suspeita conter a causa?

Eu tentei registrar e solicitar, com um diálogo, para perguntar se o programa deve pular funções.

Idealmente, gostaria de salvar o estado do processo antes (o que eu acredito) da seção com bugs e, em seguida, depurar a partir desse ponto. Eu não acho que isso seja possível.

Estou usando o C ++ no Windows com o Visual Studio. Soluções gerais bem-vindas.

    
por sudo rm -rf slash 18.12.2018 / 19:20
fonte

2 respostas

2

É possível salvar cálculos parciais? Nesse caso, você pode salvar o conjunto de cálculos que sabe ser bom, recarregá-los durante sessões futuras e continuar a depuração a partir daí.

Se os testes forem reproduzíveis, como o elemento 1.058 do 99º array do frobaz sempre acaba errado, você poderia colocar um watchpoint naquele local de memória e iniciar seus cálculos. Enquanto ele está percorrendo os cálculos lentos, você pode examinar o código manualmente para ver se alguma coisa se destaca. Eventualmente, ele irá parar quando esse elemento for modificado. De lá você pode ver onde a entrada ruim está vindo. (Provavelmente um cálculo com outro elemento ruim, então você pode tentar novamente com o elemento ).

Além disso, recomendo executar um analisador estático no seu código. Pode muito bem apontar um problema no código que você não tenha notado e apontar de onde o erro está vindo. Outras ferramentas como valgrind, sanitizante de endereços, etc. também ajudam nesse sentido.

Editar me ocorre que você pode "congelar a máquina" de certa forma. Se você tiver uma máquina virtual, poderá iniciar seu aplicativo e executar os cálculos até o ponto em que deseja iniciar a depuração. Salve o estado das VMs. Faça sua depuração. Quando você quiser retornar a esse estado, simplesmente restaure a VM para onde a salvou e comece a depurar novamente. É claro que, se você alterar qualquer código, precisará executar os cálculos novamente até o ponto em que deseja depurar.

    
por 19.12.2018 / 03:29
fonte
1

Does one know a debugging strategy which can help to reduce the waiting time until a breakpoint is reached in the area of the code which is suspected to contain the cause?

Você ainda pode definir o perfil das funções de depuração. Eu não gastaria muito tempo com isso, especialmente com um bug para consertar, mas se você tem um hotspot gritante que leva 30% do tempo ou mais na depuração, e a solução é muito simples, então pode ser uma real diferença de produtividade se os desenvolvedores estão acostumados a gastar mais de 30 minutos aguardando suas compilações de depuração para fazer algo e até mesmo ajudá-lo a corrigir esse bug mais cedo.

No meu caso, tivemos uma biblioteca matriz / vetor que funcionou muito bem em versões de release / produção, mas asperamos as assertivas em todo o lugar para nos certificarmos de que não estávamos acessando matrizes fora de campo e assim por diante nas compilações de depuração. Eu encontrei hotspots lá que foram brutos (como mais de 50% do tempo gasto em tais funções devido a asserts em todo o lugar), e acabei escrevendo um teste de unidade que garantiu que essas funções se comportassem corretamente e apenas aquelas asserts aplicada quando algo como um DEBUG_MATH_LIB (eu esqueci o que eu chamei, isso foi há muitos anos atrás) foi definido. Isso realmente acelerou a execução do software no modo de depuração substancialmente de maneiras que quando da tortura completa tentassem reproduzir problemas no depurador para não serem insuportáveis (a depuração ainda era 20 vezes mais lenta que a release, mas não 200 vezes mais lenta). / p>

Se você está tentando reproduzir um bug que resulta em falha na saída (ou falha) e demora, então normalmente minha técnica número um se aplica quando eu lidei com isso muito foi tentar jogar com o conteúdo com uma mentalidade de "pesquisa binária" e originalmente em uma compilação de lançamento (não estou executando o depurador).

Eu poderia tentar carregar uma metade do conteúdo (depois de salvar todo o conteúdo menos metade dele) e ver se ele falha. Se isso não acontecer, então eu tento a outra metade e descubro que ela falha. Em seguida, divido a segunda metade em trimestres e assim por diante, até que levem apenas alguns segundos para carregar e reproduzir o problema. Depois disso, a questão principal de que esse problema demora tanto para ser reproduzido é resolvida, e o restante é o processo doloroso de depurá-lo, sem o gargalo da espera para reproduzi-lo. Já faz muitos anos desde que eu tive que fazer esse tipo de coisa (eu encontrei projetos que evitam esse tipo de coisa na maioria das vezes), mas minhas memórias nebulosas do passado lembram muito de fazer essas coisas.

Na maioria das vezes, você não precisa carregar 3 gigabytes de dados para reproduzir um problema. O primeiro passo para mim não é descobrir o problema, mas torná-lo mais rápido para se reproduzir com essa mentalidade de "busca binária", reduzindo os dados até que fique tão pequeno que seja carregado em um piscar de olhos e cause o problema. Então eu me comprometo com o meu "modo de depuração". Esse estreitamento dos dados também tende a tornar mais óbvio que parte dele pode estar atrapalhando o software.

Ideally I would like to save the process state right before (what I believe is) the buggy section and then debug from that point. I dont think this is possible.

No Windows, pelo menos, você pode clicar com o botão direito do mouse em qualquer processo em execução e gerar um arquivo de despejo.

Você pode então abrir o arquivo .DMP resultante, digamos, no Visual Studio, e ir direto para a depuração.

Infelizmente, isso não permite retomar o processo ao meu conhecimento e deixá-lo terminar (normalmente, os despejos só são úteis para mim quando o software falha). No entanto, pode ser uma maneira de salvar um despejo de pilha e inspecionar as coisas e poder voltar e olhar para elas um pouco mais.

    
por 18.12.2018 / 20:07
fonte