Por que a depuração reversa raramente é usada? [fechadas]

O gdb implementou suporte para depuração reversa em 2009 (com gdb 7.0). Eu nunca ouvi falar sobre isso até 2012. Agora acho extremamente útil para certos tipos de problemas de depuração. Eu gostaria de ter ouvido falar disso antes.

Corrija-me se estiver errado, mas minha impressão é que a técnica ainda é raramente usada e a maioria das pessoas não sabe que ela existe. Por quê?

Você conhece alguma comunidade de programação em que o uso da depuração reversa é comum?

Informações básicas:

• Stackoverflow: Como funciona a depuração reversa?
• O gdb usa o termo "depuração reversa", mas outros fornecedores usam outros termos para técnicas idênticas ou semelhantes:
  • A Microsoft chama IntelliTrace ou "Depuração Histórica"
  • Existe um depurador reverso Java chamado Omniscient Debugger , embora provavelmente não funcione mais no Java 6
  • Existem outros depuradores reversos Java
  • O depurador do OCaml (ocamldebug) chama de viagem no tempo

Por um lado, a execução no modo de depuração com a gravação ativada é muito cara em comparação com o modo de depuração normal; também consome muito mais memória.

É mais fácil diminuir a granularidade do nível da linha para o nível da chamada da função. Por exemplo, o depurador padrão no eclipse permite que você "solte no quadro", que é essencialmente um retorno ao início da função com uma redefinição de todos os parâmetros (nada feito no heap é revertido e os finallyblocos não são executados , portanto, não é um verdadeiro depurador reverso; tenha cuidado com isso).

Observe que isso já está disponível há vários anos e funciona de mãos dadas com a substituição de código quente.

Como já mencionado, o desempenho é fundamental, por exemplo, com a depuração reversível do gdb, executando algo como o gzip vê uma desaceleração de 50.000x em comparação com a execução nativa. No entanto, existem alternativas comerciais: trabalho para o Undo undo.io e o nosso produto UndoDB faz o mesmo, mas com uma desaceleração menor que 2x. Existem outros depuradores reversíveis comerciais disponíveis também.

Para uma visão geral das opções e produtos de tecnologia, consulte uma série de postagens que escrevi há cerca de um ano (e alguns acompanhamentos desde então):

• http://jakob.engbloms.se/archives/1547 - a tecnologia
• http://jakob.engbloms.se/archives/1554 - pesquisa
• http://jakob.engbloms.se/archives/1564 - produtos
• http://jakob.engbloms.se/archives/1768 - atualizações para a postagem anterior

Meu sentimento por que é usado tão pouco é que requer hardware especial, ou usando um depurador especial, ou configurando o sistema corretamente. Infelizmente, a maioria das pessoas não investe tempo para obter o máximo valor de suas ferramentas de depuração.

E o fato de que o "padrão barato" do gdb é quase inutilmente lento e tem alguns problemas de estabilidade para tudo, exceto os sistemas de destino mais comuns.

Pela minha experiência como engenheiro de vendas do depurador TotalView, as pessoas sabem que ele existe, mas não acham que ele funciona, independentemente da desaceleração (aceitável ou não).

A Universidade de Cambridge recentemente fez uma pesquisa intitulada "Falha na adoção de custos reversos de depuração na economia global de US $ 41 bilhões anualmente" .

E voltando ao GDB, ouvi (muito) que a desaceleração o torna bastante inutilizável em um aplicativo "da vida real".

Pessoalmente, eu adoraria ouvir mais pessoas usando a depuração reversa em aplicativos que não sejam "Hello world!"

Eu acho que é importante expandir um pouco mais essa depuração "reversa" ou "histórica". Eu acho que entender sistemas e comportamentos complexos nesses, reproduzir "eventos" que explicitam o estado é absolutamente crucial.

O que quero expressar é que você não está sozinho se perguntando por que essa técnica não é tão aplicada hoje em dia ou por que os problemas relacionados raramente são discutidos claramente.

Então, vamos enfatizar dois conceitos muito importantes aqui:

1.Para entender um sistema de programação, é útil tornar explícito o estado

2.Para entender ainda mais um sistema de programação, reproduzir sequências de estado (eventos) pode ajudar muito.

Aqui estão algumas fontes que abordaram o problema e propuseram ou projetaram soluções para o problema (lidando com o estado em sistemas complexos):

- Fora do bit de tar, artigo: http://shaffner.us/cs/papers/tarpit.pdf Principais idéias: evitar, isolar ou tornar explícito o estado

-CQRS http://www.cqrs.nu/ Essa é uma combinação de dois conceitos: Segregação de consulta de comando e fornecimento de eventos. Existem implementações diferentes (Java, C #, Scala). A repetição de seqüências Tate e a evolução de um modelo de domínio são as partes cruciais aqui.

Se você realmente diminui o zoom e vê uma imagem muito ampla, já pode ver que, com o "aumento" da programação funcional, as pessoas já são (inconscientemente) atraídas pelo fp porque torna explícito o estado! Mas isso só lida com o ponto um. Para abordar o segundo, você precisa de outro conceito que possa ser "vagamente" descrito como programação reativa funcional.

Então você pode dizer tudo muito bem, mas quem realmente usa CQRS e FRP? Eu diria (na OMI porque não tenho números concretos), na verdade, muitas empresas são apenas porque elas não sabem o trabalho que realizam com essa terminologia. Talvez você pesquise um pouco e tenha notícias de empresas que usam o CQRS, já existem algumas histórias de sucesso por aí. O FRP também está subindo lentamente como um exemplo que eu poderia dar à Netflix: http://techblog.netflix.com/2013/02/rxjava-netflix-api.html Que acabou de lançar uma implementação do RX que é realmente baseada em .NET (mas tem uma implementação Javascript também). Então, as pessoas já estão usando essas técnicas hoje, IN GRANDE para entender sistemas complexos e torná-los ainda melhores. É por isso que eles usam técnicas de depuração reversa.