Heisenbug

Origem: Wikipédia, a enciclopédia livre.

No jargão da programação de computadores, heisenbug é um bug de software que parece desaparecer ou alterar seu comportamento quando se tenta estudá-lo. [1] O termo é um trocadilho com o nome de Werner Heisenberg, o físico que primeiro afirmou o efeito observador da mecânica quântica, que afirma que o ato de observar um sistema altera inevitavelmente seu estado. Em eletrônica, o termo tradicional é efeito de prova, em que anexar uma ponta de prova a um dispositivo muda seu comportamento.

Termos semelhantes, como bohrbug, mandelbug, [2] [3] [4] hindenbug e schrödinbug [5] [6] (consulte a seção sobre termos relacionados) foram ocasionalmente propostos para outros tipos de bugs de software incomuns, às vezes em tom de humor; [7] [8] no entanto, ao contrário do termo heisenbug, eles não são amplamente conhecidos ou usados. [9]

Exemplos[editar | editar código-fonte]

Heisenbugs ocorrem porque tentativas comuns de depurar um programa, como inserir instruções de saída ou executá-lo com um depurador, geralmente têm o efeito colateral de alterar o comportamento do programa de maneiras sutis, como alterar os endereços de memória de variáveis e o tempo de sua execução.

Um exemplo comum de heisenbug é um bug que aparece quando o programa é compilado com um compilador com suporte a otimização, mas não quando o mesmo programa é compilado sem otimização (como geralmente é feito com o propósito de examiná-lo com um depurador). Durante a depuração, os valores que um programa otimizado normalmente manteria nos registros são frequentemente colocados na memória principal. Isso pode afetar, por exemplo, o resultado de comparações de ponto flutuante, uma vez que o valor na memória pode ter alcance e precisão menores do que o valor no registrador. Da mesma forma, Heisenbugs podem ser causados por efeitos colaterais em expressões de teste usadas em asserções de tempo de execução em linguagens como C e C++, onde a expressão de teste não é avaliada quando as asserções são desativadas no código de produção usando a macro NDEBUG .

Outras causas comuns de heisenbugs são usar o valor de uma variável não inicializada (que pode mudar seu endereço ou valor inicial durante a depuração) ou seguir um ponteiro inválido (que pode apontar para um local diferente durante a depuração). Os depuradores geralmente permitem o uso de breakpoints ou fornecem outras interfaces de usuário que fazem com que o código-fonte adicional (como acessadores de propriedade) seja executado furtivamente, o que pode, por sua vez, alterar o estado do programa. [10]

O tempo também pode ser um fator em heisenbugs, particularmente com aplicativos multi-thread. A execução de um programa sob controle de um depurador pode alterar o tempo de execução do programa em comparação com a execução normal. Erros sensíveis ao tempo, como condições de corrida, podem não ocorrer quando o programa é retardado por linhas de origem de passo único no depurador. Isso é particularmente verdadeiro quando o comportamento envolve interação com uma entidade que não está sob o controle de um depurador, como ao depurar o processamento de pacotes de rede entre duas máquinas e apenas uma está sob o controle do depurador.

Heisenbugs podem ser vistos como exemplos do efeito do observador na tecnologia da informação . Programadores frustrados podem culpar humoristicamente um heisenbug às fases da lua, [11] ou (se ocorreu apenas uma vez) podem explicar como um erro leve devido a partículas alfa ou raios cósmicos afetando o hardware.

Termos relacionados[editar | editar código-fonte]

Um bohrbug, por oposição, é um "bug bom e sólido". Como o modelo de átomo de Bohr determinístico, eles não mudam seu comportamento e são detectados com relativa facilidade. [12] [13]

Um mandelbug (batizado em homenagem ao fractal de Benoît Mandelbrot) é um bug cujas causas são tão complexas que não podem ser reparadas ou fazem seu comportamento parecer caótico ou mesmo não determinístico. [2] O termo também se refere a um bug que exibe um comportamento fractal (ou seja, auto-similaridade), revelando mais bugs (quanto mais fundo um desenvolvedor vai no código para corrigi-lo, mais bugs ele encontra). 

Um schrödinbug ou schroedinbug (nomeado em homenagem a Erwin Schrödinger e seu experimento de pensamento) é um bug que se manifesta na execução de software depois que um programador percebe que o código nunca deveria ter funcionado. [5]

Um hindenbug (nomeado após o desastre de Hindenburg) é um bug com comportamento catastrófico.

Um higgs-bugson [14] [15] (nomeado após a partícula do bóson de Higgs) é um bug que deve existir com base em outras condições observadas (mais comumente, entradas de log vagamente relacionadas e relatórios de usuários anedóticos), mas é difícil, senão impossível, para reproduzir artificialmente em um ambiente de desenvolvimento ou teste. O termo também pode se referir a um bug que é óbvio no código (matematicamente comprovado), mas que não pode ser visto em execução (ainda que difícil ou impossível de realmente encontrar).

História do termo[editar | editar código-fonte]

O termo também foi usado em 1985 por Jim Gray, em um artigo sobre falhas de software [16] (e às vezes é erroneamente atribuído a ele por causa desta publicação) e também em 1986 por Jonathan Clark e Zhahai Stewart na lista de discussão (posteriormente Usenet grupo de notícias) comp.risks . [17]

Bruce Lindsay, pesquisador da IBM, afirmou em uma entrevista da ACM Queue em 2004 que estava presente quando o Heisenbug foi originalmente definido. [18]

Uma aparição anterior nas publicações da ACM é de 1983. [19]

Resolução[editar | editar código-fonte]

Heisenbugs são difíceis de identificar e corrigir; muitas vezes, a tentativa de resolvê-los leva a mais comportamentos inesperados. Como o problema se manifesta como resultado de um bug de base separado, o comportamento pode ser difícil de prever e analisar durante a depuração. No geral, o número de heisenbugs identificados deve diminuir à medida que um software amadurece. [20]

Referências

  1. ↑ «The Jargon File: heisenbug» 
  2. ↑ a b «The Jargon File: Mandelbug». Catb.org. Consultado em 5 de setembro de 2013 
  3. ↑ Raymond, Eric S.; The New Hacker's Dictionary, 3rd edition, 1996
  4. ↑ Clarke, Arthur C., The Ghost from the Grand Banks, Bantam Books, 1990
  5. ↑ a b «The Jargon File: Schroedinbug». Catb.org. Consultado em 5 de setembro de 2013 
  6. ↑ Raymond, Eric S.; The New Hacker's Dictionary, 3rd edition, 1996
  7. ↑ The following article investigates the various definitions of bohrbug, mandelbug and heisenbug proposed in the literature, as well as the statements made about the relationships between these fault types: Grottke, Michael; and Trivedi, Kishor S.; Software Faults, Software Aging and Software Rejuvenation, Journal of the Reliability Engineering Association of Japan, Vol. 27, No. 7, pp. 425–438, 2005.
  8. ↑ Grottke, Michael; and Trivedi, Kishor S.; Fighting Bugs: Remove, Retry, Replicate, and Rejuvenate, IEEE Computer vol. 40, no. 2 (February 2007), pp. 107–109
  9. ↑ A February 2012 Google Books search returns about 70 hits for "schroedinbug", 100 for "mandelbug", 400 for "bohrbug" or "heisenbug".
  10. ↑ "Java toString() override with initialization as a side effect" Arquivado em 2014-12-30 no Wayback Machine
  11. ↑ CATB.org, "phase of the moon"
  12. ↑ Goshgarian, Gary; Exploring Language, HarperCollins College Publishers, 1995
  13. ↑ "Such transient software failures have been given the whimsical name 'Heisenbug' because they disappear when reexamined. By contrast, 'Bohrbugs' are good solid bugs." (IEEE Computer Group News, Volume 24, Numbers 7–12, 1991)
  14. ↑ «New Programming Jargon» 
  15. ↑ «20 Hilarious Programming Jargon Phrases You Should Use When Talking to Engineers» 
  16. ↑ Gray, Jim (1985). «Why Do Computers Stop And What Can Be Done About It?». Technical Report 85.7. Tandem Computers 
  17. ↑ (16 December 1986) RISKS DIGEST 4.30 - (23 December 1986) RISKS DIGEST 4.34, moderated by Peter G. Neumann
  18. ↑ «"A Conversation with Bruce Lindsay", ACM Queue vol. 2, no. 8 - November 2004». Queue.acm.org. Consultado em 5 de setembro de 2013 
  19. ↑ Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering Symposium on High-Level Debugging, Pacific Grove, California, March 20–23, 1983, Association for Computing Machinery, 1983, Google Books search:
    This is the Heisenberg Uncertainty Principle as applied to debugging (an instance of such a bug was called a "Heisenbug" by one participant.)
  20. ↑ P., Birman, Kenneth (2005). Reliable distributed systems : technologies, Web services, and applications. Springer. New York: [s.n.] ISBN 0387276017. OCLC 225378026 

Ligações externas[editar | editar código-fonte]

Obtida de "https://pt.wikipedia.org/w/index.php?title=Heisenbug&oldid=59700978"