10 de janeiro de 2026

Recentemente, usuários relataram que o Ghostty estava consumindo uma quantidade absurda de memória, com um deles informando 37 GB após 10 dias de funcionamento. Hoje, temos boas notícias: a correção foi encontrada e integrada. Este artigo apresenta uma visão geral sobre a causa do vazamento, além de um olhar sobre a estrutura interna do Ghostty e um resumo de como rastreamos o problema.

O problema existia desde pelo menos a versão 1.0 do Ghostty, mas somente agora, com o uso crescente de aplicações de CLI populares como o Claude Code, as condições necessárias para acionar o vazamento foram atingidas em larga escala. A dificuldade em diagnosticar o problema está nas condições limitadas que o acionavam.

O vazamento foi relacionado à forma como o Ghostty gerencia a memória do terminal, utilizando uma estrutura de dados chamada PageList, que é uma lista duplamente encadeada de páginas de memória. Essa estrutura armazena o conteúdo do terminal, incluindo caracteres, estilos e hyperlinks.

A correção já está disponível nas versões diárias e fará parte do lançamento marcado 1.3 em março.

Para entender o bug, é preciso compreender como a alocação de memória ocorre no Ghostty. As páginas são alocadas usando mmap, e para evitar constantes chamadas de sistema, um pool de memória é utilizado. Quando uma nova página é necessária, retiramos do pool, e ao final do uso, devolvemos para reaproveitamento.

Uma parte crucial do problema foi a otimização do pruning do scrollback. O Ghostty possui uma configuração que limita a quantidade de histórico mantido. Quando esse limite é atingido, as páginas mais antigas são removidas para liberar memória. A otimização consiste em reutilizar a página mais antiga como a mais nova, evitando alocações adicionais e acelerando a operação.

Entretanto, durante esse processo, ocorreu um erro de lógica: ao redimensionar a página, a memória subjacente não era alterada, apenas as informações de metadados. Isso fez com que a PageList acreditasse que a página era de tamanho padrão, embora a alocação de memória fosse a de uma página não padrão, resultando em um vazamento quando a memória era liberada sem chamar munmap.

A solução para o problema é simples: nunca reutilizar páginas não padrão durante o pruning do scrollback. Se uma página não padrão for encontrada, ela deve ser destruída corretamente, chamando munmap, e uma nova página padrão deve ser alocada do pool.

Além disso, foram adicionados suportes para tags de memória virtual no macOS, facilitando a identificação de alocações de memória durante o processo de depuração. Isso possibilitou associar o vazamento à PageList e verificar se a correção funcionou adequadamente.

O Ghostty tem implementado diversas medidas para detectar e evitar vazamentos de memória. Em builds de debug, utilizamos alocadores que detectam vazamentos, e executamos o valgrind em toda a suíte de testes para identificar problemas de uso indefinido de memória.

Apesar de todos os esforços, esse vazamento específico não foi detectado anteriormente devido às condições raras que o acionavam. A PR que foi integrada inclui um teste que reproduz o vazamento para evitar regressões futuras.

Agradecemos a @grishy, que ajudou a fornecer uma reprodução confiável do problema, permitindo uma análise mais eficaz. Essa foi a maior falha conhecida de vazamento de memória no Ghostty até o momento, e continuaremos monitorando e lidando com esses relatórios à medida que surgirem.