O bug do Word 97 que sumia toda vez que os engenheiros olhavam para ele
Pouco antes do lançamento do Office 97, o Word travava em testes, mas o erro desaparecia sempre que os desenvolvedores tentavam investigar com debugger. A causa era uma falha de hardware.
Por Marcos Silva · Repórter de plantão
O crash que só aparecia longe dos olhos
Na reta final do desenvolvimento do Word 97, a equipe de testes da Microsoft encontrou um bug capaz de travar o programa. O problema era grave o suficiente para colocar o lançamento em risco.
A equipe de QA montou um script que reproduzia o travamento em laboratório com boa taxa de acerto. O problema começava quando alguém tentava investigar a fundo.
Ao rodar o mesmo código dentro de um debugger, o crash simplesmente não acontecia. Fora do debugger, o erro voltava a ocorrer de forma esporádica.
Um bug que se comporta como fantasma
Esse tipo de defeito tem nome: heisenbug. É uma referência ao princípio da incerteza de Heisenberg, usada para descrever falhas que mudam de comportamento quando são observadas.
Para a equipe do Word, a situação gerava um problema prático. Um bug raro em laboratório tende a aparecer com frequência maior quando o software chega a milhões de usuários.
Chegou a ser cogitado o uso de um in-circuit emulator, equipamento que substitui o processador por um cabo ligado a outro computador para rodar a emulação. A ideia foi descartada.
A causa era o processador, não o código
A investigação levou a equipe a cruzar os relatos de travamento com o fabricante e a data de fabricação das máquinas usadas nos testes. O padrão apontou para uma errata de CPU, falha conhecida de hardware presente em processadores fabricados antes de uma determinada data.
O defeito só se manifestava quando uma sequência específica de instruções cruzava um limite de página de memória. Entre 150 trechos de código com esse padrão, apenas um reunia essa condição exata.
A correção veio por fora do compilador
O projeto já estava em fase de escrow, quando qualquer alteração de última hora é tratada como risco. Trocar de versão do compilador não era opção segura àquela altura.
A equipe optou por um patch binário: localizou a sequência de código problemática já compilada e inseriu uma instrução nop, que não faz nada, apenas para quebrar o padrão que disparava o errata da CPU.
A história voltou a circular após o veterano da Microsoft Raymond Chen relatar o caso em seu blog Old New Thing, dedicado a bastidores do desenvolvimento da empresa.