Bugs silenciosos em C - Vol. 1: O caso Therac-25 e demonstrações em hardware

Problema 1: Race Condition

• O software era multitarefa preemptivo, com diversas tarefas acessando variáveis globais compartilhadas.
• Não havia mecanismos adequados de sincronização (mutex, semáforos ou operações atômicas).
• Flags e variáveis de controle eram lidas e escritas de forma não atômica, ou seja, essas ações poderiam ser interrompidas antes de sua conclusão.
• O operador frequentemente selecionava o modo "X" (Raio-X), percebia o erro e alterava rapidamente para "E" (Elétron).

O bug:
O software levava aproximadamente 8 segundos para configurar os ímãs de curvatura responsáveis pela seleção de energia. Se o operador corrigisse o modo e pressionasse Enter dentro desse intervalo, ocorria uma condição de corrida (Race condition) entre a tarefa de entrada de dados e as tarefas de configuração do hardware. Como resultado, o sistema avançava para a fase de tratamento antes que todas as variáveis internas fossem atualizadas de forma consistente.

Resultado:

• A interface indicava corretamente o modo "Elétron", mas internamente o sistema configurava a máquina com parâmetros de alta energia típicos do modo "Raio-X", sem o alvo e o filtro de espalhamento posicionados. Isso resultava em um feixe de elétrons altamente concentrado e de intensidade letal.
• ➡️ Bug silencioso clássico: o sistema aparentava estar em um estado seguro, enquanto internamente operava em uma condição fisicamente inválida.

Problema 2: Estouro de variável (Integer Overflow)

• O software utilizava variáveis inteiras de tamanho reduzido para armazenar contadores, estados e valores acumulados relacionados à operação do equipamento.
• Não havia validação explícita de limites antes de operações aritméticas, assumindo-se implicitamente que os valores nunca ultrapassariam a capacidade do tipo.
• O código era escrito em C, linguagem que não fornece qualquer mecanismo automático de detecção de estouro de variáveis inteiras.

O bug:
Quando uma variável inteira atinge o valor máximo que pode ser representado pelo seu tipo e sofre um incremento adicional, ocorre um estouro de variável. Em inteiros sem sinal, o valor simplesmente “volta” para zero e continua a contar. Esse comportamento acontece de forma silenciosa, sem erro de compilação, sem exceção em tempo de execução e sem qualquer alerta ao software.

Resultado:

• No Therac-25, variáveis relacionadas a estado operacional e parâmetros de tratamento podiam sofrer esse tipo de estouro, permitindo que o sistema avançasse para fases perigosas da operação enquanto aparentava estar em um estado seguro.
• ➡️ Bug silencioso clássico: o valor interno da variável parece válido, mas representa um estado logicamente impossível do ponto de vista do projeto do sistema.

Exemplo simplificado em C:

Estouro silencioso de variável inteira

    #include <stdint.h>

    int main(void)
    {
        uint8_t counter = 250;

        counter += 10;

        while (counter < 100)
        {
            // loop inesperado
        }

        return 0;
    }
      

O que o programador espera:
O valor inicial de counter é 250. Após o incremento de 10, o valor esperado seria 260, fazendo com que a condição do while fosse falsa e o laço não fosse executado.

O que realmente acontece:
A variável counter é do tipo uint8_t, que só consegue armazenar valores entre 0 e 255. Ao tentar armazenar o valor 260, ocorre um estouro e o valor resultante passa a ser 4 (260 módulo 256).

• O código compila normalmente.
• O programa executa sem travar.
• Nenhum erro é sinalizado pelo sistema.
• A lógica de controle do software é alterada silenciosamente.

Resultado:

• A condição counter < 100 torna-se verdadeira, levando o sistema a entrar em um laço inesperado ou a seguir um caminho lógico não previsto.

Teste prático

O objetivo deste experimento é demonstrar, de forma prática e observável em hardware real, a ocorrência simultânea de race condition e overflow silencioso de variável em um sistema multitarefa preemptivo. O cenário foi intencionalmente simplificado para evidenciar como falhas sutis em C podem produzir estados logicamente impossíveis, apesar de o programa permanecer aparentemente funcional.

Ambiente e ferramentas utilizadas

• Placa de desenvolvimento AM243x LaunchPad Development Kit (Texas Instruments), baseada em núcleo ARM Cortex-R5F, representativa de sistemas embarcados de tempo real com requisitos de determinismo.
• FreeRTOS, executando em modo preemptivo, permitindo concorrência real entre múltiplas tarefas.
• MCU+ SDK da Texas Instruments, utilizando como base o exemplo UART Echo com FreeRTOS, empregado apenas como infraestrutura mínima de inicialização do sistema operacional.
• Code Composer Studio (CCS) (versão 20.3.0.14__1.9.0), utilizado para compilação, carga do firmware e depuração via JTAG.
• Instrumentação por meio do CIO (C I/O) do CCS, mecanismo no qual funções como DebugP_log são redirecionadas pelo debugger via JTAG, permitindo observar o comportamento interno do sistema sem utilizar UART física e sem interferir diretamente no escalonamento das tarefas.

Ideia central do experimento

Neste experimento é utilizada uma variável global de estado, compartilhada entre múltiplas tarefas de um sistema multitarefa preemptivo. Essa variável representa um estado interno do sistema e é manipulada concorrentemente por duas tarefas independentes, sem qualquer mecanismo de proteção, como mutexes, seções críticas ou operações atômicas.

Cada tarefa atualiza a mesma variável global utilizando taxas de crescimento diferentes e períodos distintos de execução. Uma tarefa incrementa o estado de forma lenta e incremental, enquanto a outra aplica incrementos maiores e mais frequentes. Essa combinação cria, de forma intencional, um cenário clássico de race condition, no qual o valor final da variável passa a depender da ordem não determinística de execução das tarefas.

Além disso, a variável de estado foi propositalmente definida com um tipo inteiro de largura reduzida (uint8_t), tornando inevitável a ocorrência de overflow silencioso. O resultado observado é um estado que permanece válido do ponto de vista da linguagem C, mas que assume valores logicamente impossíveis sob a ótica do sistema.

O objetivo do experimento não é provocar falhas explícitas ou travamentos, mas demonstrar como falhas silenciosas podem surgir em sistemas aparentemente funcionais quando variáveis globais são compartilhadas de forma insegura em ambientes preemptivos.

Variável global compartilhada sem proteção

  volatile uint8_t system_state = 0;
  

A variável system_state representa o estado global do sistema. O qualificador volatile informa ao compilador que o valor da variável pode mudar a qualquer momento, impedindo que ele otimize o acesso mantendo o valor em um registrador. No entanto, o volatile não garante atomicidade, não cria barreiras de memória (memory barriers) e não substitui mecanismos de sincronização de hardware.

Task A — Atualização incremental do estado

  void OperatorTask(void *pvParameters)
  {
      (void)pvParameters;

      for (;;)
      {
          system_state++;   /* Escrita não atômica */
          vTaskDelay(pdMS_TO_TICKS(200));
      }
  }
  

Esta tarefa simula uma interação gradual com o sistema, incrementando o estado global de forma periódica. A operação system_state++ não é atômica e envolve múltiplas etapas internas (leitura, cálculo e escrita), tornando-se vulnerável à preempção por outras tarefas.

Task B — Atualização concorrente e mais agressiva

  void ControlTask(void *pvParameters)
  {
      (void)pvParameters;

      for (;;)
      {
          system_state += 10;   /* Escrita concorrente */
          vTaskDelay(pdMS_TO_TICKS(150));
      }
  }
  

Esta tarefa representa uma lógica interna de controle do sistema e modifica a mesma variável global, porém com incrementos maiores e maior frequência. Executando em paralelo com a tarefa do operador, ela cria uma condição de corrida real, na qual atualizações podem ser sobrescritas ou perdidas.

Task de monitoramento do estado global

  void LoggerTask(void *pvParameters)
  {
      (void)pvParameters;

      for (;;)
      {
          DebugP_log(
              "[tick=%lu] system_state=%u\r\n",
              xTaskGetTickCount(),
              system_state
          );

          vTaskDelay(pdMS_TO_TICKS(500));
      }
  }
  

A tarefa de monitoramento observa passivamente o valor do estado global e registra sua evolução ao longo do tempo por meio do mecanismo de C I/O (CIO) do ambiente de depuração. Essa separação permite coletar evidências do problema sem interferir diretamente no comportamento das tarefas que manipulam o estado.

Criação das tarefas e preempção

  void freertos_main(void *args)
  {
      (void)args;

      xTaskCreate(OperatorTask, "Operator", 1024,
                  NULL, tskIDLE_PRIORITY + 2, NULL);

      xTaskCreate(ControlTask, "Control", 1024,
                  NULL, tskIDLE_PRIORITY + 3, NULL);

      xTaskCreate(LoggerTask, "Logger", 1024,
                  NULL, tskIDLE_PRIORITY + 1, NULL);

      vTaskDelete(NULL);
  }
  

As tarefas são criadas com prioridades distintas, garantindo a ocorrência de preempção. Como não há qualquer forma de sincronização, o valor final da variável global passa a depender da ordem de execução das tarefas, resultando em race conditions e overflows silenciosos, observáveis diretamente nos logs do sistema.