Gerenciamento de memória dinâmica em C

O endereço de uma variável informa onde seus dados estão. Sua duração de armazenamento informa por quanto tempo esses dados existem. Guardar um endereço não mantém o objeto vivo.

Três tempos de vida

Em sistemas comuns, objetos automáticos usam a pilha de chamadas, e blocos alocados usam o heap. C define os tempos de vida; não exige essas regiões físicas. O código de máquina e os dados estáticos ocupam outras regiões, cuja disposição depende do sistema.

Uma chamada de função normalmente cria um registro de ativação que contém seus parâmetros, variáveis locais e informações de retorno. As chamadas se aninham: o registro mais recente é removido primeiro. O retorno libera o armazenamento automático daquela chamada, então chamadas posteriores podem reutilizar o espaço. O alocador do heap gerencia uma área separada. Ele reserva um bloco contíguo mediante solicitação e fornece seu endereço inicial. Retornar de uma função não libera esse bloco.

O ponteiro e seu bloco são objetos separados

Considere esta função, declarada com <stdlib.h> disponível:

int *make_array(size_t n) {
    if (n == 0 || n > SIZE_MAX / sizeof(int)) return NULL;
    int *p = malloc(n * sizeof *p);
    if (p == NULL) return NULL;
    return p;
}

SIZE_MAX vem de <stdint.h>. Quando main chama int *nums = make_array(5);, o parâmetro n e a variável ponteiro p pertencem à chamada. O arranjo alocado não pertence. Quando um int ocupa 4 bytes, o bloco contém 20 bytes. O retorno copia seu endereço para nums; não copia o arranjo. A função chamadora verifica nums, usa os elementos depois de atribuir valores a eles e, por fim, libera o bloco.

A variável local p deixa de existir quando a função retorna. O bloco permanece porque sua duração de armazenamento é alocada, não automática. Essa distinção também funciona no sentido inverso: um ponteiro local pode apontar para um objeto global, e um ponteiro global pode apontar para um bloco no heap.

Dados estáticos sobrevivem às chamadas

int next_id(void) {
    static int id = 0;
    return ++id;
}

Chamadas sucessivas retornam 1, 2 e 3. O inicializador executa uma vez, e id existe durante toda a execução do programa. Remover static cria uma nova variável automática id, inicializada em zero, a cada chamada; assim, cada chamada retorna 1.

O espaço da pilha é limitado

Um arranjo local grande e chamadas aninhadas em muitos níveis consomem espaço na pilha. Ultrapassar o limite causa um estouro de pilha, que geralmente encerra o programa. Muitas configurações do Linux permitem uma pilha de 8 MiB; a reserva padrão da pilha da thread principal da Microsoft é geralmente 1 MiB. Essas são configurações do sistema, não regras de C. Um arranjo local de 4.000.000 de valores int precisa de 16.000.000 bytes quando um int ocupa 4 bytes, cerca de 15,3 MiB.

A alocação no heap tem custos de controle ao reservar e liberar blocos. Ler um elemento não é inerentemente mais lento apenas porque seu arranjo está no heap. Além disso, a área de memória do heap não tem relação com a estrutura de dados heap usada em uma fila de prioridade.

Escolha o armazenamento perguntando quanto espaço é necessário, quando esse tamanho se torna conhecido e por quanto tempo os dados devem existir. A solução adequada mais simples costuma ser um arranjo local comum.

Escolha o armazenamento conforme os dados

As temperaturas diárias de uma semana precisam de sete valores, então double temps[7]; é um arranjo local natural. Uma nota por estudante exige um tamanho obtido em tempo de execução. Para n estudantes, use double *grades = malloc(n * sizeof *grades); depois de verificar o tamanho. Para 250 estudantes e valores double de 8 bytes, a solicitação é de 2.000 bytes. Depois, verifique o resultado antes de preencher o arranjo.

Por que retornar um buffer local falha

char *greeting(void) {
    char buf[16] = "hello";
    return buf;  /* error: buf ends when this call returns */
}

O endereço retornado não pode prolongar o tempo de vida de buf. A função chamadora recebe um ponteiro pendente, mesmo que os bytes antigos pareçam inalterados. GCC e Clang podem emitir avisos sobre esse padrão.

Uma correção é deixar a função chamadora fornecer o armazenamento:

#include <string.h>

void greeting(char out[16]) {
    strcpy(out, "hello");
}

/* In the caller: */
char message[16];
greeting(message);

Aqui, o arranjo da função chamadora permanece vivo durante toda a chamada e depois dela. O parâmetro ainda se comporta como um ponteiro; a função chamadora deve fornecer espaço suficiente. Uma segunda solução aloca um resultado no heap e torna a função chamadora responsável por liberá-lo. Uma terceira retorna um buffer estático. Esse buffer permanece, mas todas as funções chamadoras o compartilham, e uma chamada posterior pode sobrescrever seu conteúdo. Escolha com base na necessidade de resultados independentes pelas funções chamadoras.

Tamanho em tempo de execução nem sempre significa heap

O C99 introduziu arranjos de tamanho variável, como int a[n];. Eles têm armazenamento automático, geralmente na pilha. O C11 tornou o suporte opcional, e o compilador da Microsoft não oferece suporte a eles. Uma entrada grande pode esgotar a pilha, e a declaração do arranjo não fornece um resultado nulo a verificar. A alocação no heap oferece um caminho de falha verificável e permite o redimensionamento posterior.

Um ponteiro não indica responsabilidade pela liberação

int value = 3;
int *p = &value;

p aponta para um objeto automático. Passá-lo a free é inválido. A mesma regra impede a liberação de um arranjo estático ou de um literal de cadeia de caracteres. O endereço deve pertencer a uma alocação ainda válida pela qual o programa seja responsável.

Da mesma forma, char *s = "hello"; aponta para um literal de cadeia de caracteres; não cria uma cópia na qual se possa escrever. Modificar o literal é comportamento indefinido. Use char s[] = "hello"; para uma cópia local gravável ou aloque espaço para uma cópia separada no heap.

malloc reserva um bloco contíguo de bytes e retorna seu endereço inicial. Inclua <stdlib.h> para obter sua declaração. Uma alocação bem-sucedida fornece armazenamento, mas não o preenche com valores úteis.

Conte os elementos e determine o tamanho de cada um

int *nums = malloc(n * sizeof *nums);

n é uma quantidade de elementos; sizeof *nums é a quantidade de bytes por elemento. A multiplicação fornece a quantidade de bytes. Quando um int ocupa 4 bytes, dez valores int precisam de 40 bytes. Dez valores double de 8 bytes precisam de 80 bytes. Dez ponteiros precisam de 80 bytes quando cada ponteiro ocupa 8 bytes. Um char ocupa sempre um byte de C.

A forma sizeof *nums acompanha o tipo apontado se a declaração mudar. Para esse tipo comum, que não tem tamanho variável, sizeof não avalia *nums, então não desreferencia um ponteiro não inicializado. Em C, o void * retornado é convertido no tipo de ponteiro para objeto sem uma conversão explícita.

malloc(n) aloca n bytes, não n valores int. sizeof nums mede a variável ponteiro, não um elemento ou o bloco inteiro. Em um sistema com ponteiros de 8 bytes e valores int de 4 bytes, malloc(n * sizeof nums) solicita o dobro do espaço necessário, mascarando a expressão incorreta. Com outros tipos, pode alocar espaço insuficiente.

Verifique o tamanho e a falha antes do uso

Este programa completo rejeita uma solicitação vazia, protege a multiplicação, verifica a alocação e inicializa cada elemento:

#include <stdint.h>
#include <stdlib.h>

int main(void) {
    size_t n = 5;
    int *nums;
    if (n == 0 || n > SIZE_MAX / sizeof *nums) {
        return EXIT_FAILURE;
    }
    nums = malloc(n * sizeof *nums);
    if (nums == NULL) return EXIT_FAILURE;

    for (size_t i = 0; i < n; ++i) {
        nums[i] = (int)(i * i);
    }
    free(nums);
    return EXIT_SUCCESS;
}

SIZE_MAX, de <stdint.h>, é o maior valor de size_t. Verifique com divisão antes da multiplicação. Se o produto sofrer redução modular primeiro, verificar o resultado reduzido não pode recuperar o tamanho pretendido. Uma solicitação diferente de zero pode falhar mesmo quando seu cálculo cabe no tipo, então a verificação de ponteiro nulo é uma etapa separada.

Os valores inicializados aqui são 0, 1, 4, 9 e 16. nums[i] acessa o mesmo elemento que *(nums + i). A aritmética de ponteiros avança em elementos, então o código não multiplica i pelo tamanho em bytes.

Mantenha a quantidade junto ao ponteiro

Não há operação padrão em C que recupere a quantidade de elementos de uma alocação a partir de seu ponteiro. Armazene n separadamente e passe o ponteiro e a quantidade às funções. A quantidade controla os laços e as verificações de índice.

Uma cadeia copiada precisa de seus caracteres e do terminador '\0'. A cadeia “Amsterdam” tem nove caracteres e precisa de dez bytes, então solicite strlen(s) + 1 para sua cópia. <string.h> fornece strlen.

Uma solicitação a malloc de tamanho zero pode retornar um ponteiro nulo ou um ponteiro que pode ser liberado, mas não desreferenciado. Trate quantidades iguais a zero como um caso vazio explícito, em vez de tratar esse ponteiro como armazenamento utilizável para um arranjo.

Um contador precisa de um valor inicial definido antes do primeiro incremento. calloc combina alocação e preenchimento com zeros, então um arranjo de contadores inteiros está pronto para contar após a verificação de falha.

Dois argumentos descrevem o arranjo

Inclua <stdlib.h> e escreva:

int *tally = calloc(26, sizeof *tally);
if (tally == NULL) return EXIT_FAILURE;

O primeiro argumento é a quantidade de elementos e o segundo é o tamanho de um elemento. Quando um int ocupa 4 bytes, isso reserva 104 bytes. Cada byte começa em zero, então cada contador inteiro começa em zero. Chamar calloc com um único argumento combinado não compila; sua interface exige dois argumentos.

Para a palavra “banana”, incremente o contador correspondente a cada letra. Após processá-la, os contadores de a, b e n contêm 3, 1 e 2. Todos os outros permanecem em zero. Em uma codificação de caracteres com letras minúsculas consecutivas, a expressão do índice é c - 'a'. A entrada deve ser uma letra minúscula antes de essa expressão ser usada como índice de arranjo.

#include <stdlib.h>

int main(void) {
    int *counts = calloc(3, sizeof *counts);
    if (counts == NULL) return EXIT_FAILURE;
    counts[1]++;
    counts[1]++;
    /* The counters now hold 0, 2, 0. */
    free(counts);
    return EXIT_SUCCESS;
}

Apenas o contador do meio foi alterado pelo código de contagem. Seus dois vizinhos ainda têm valores úteis porque a alocação os preencheu com zeros.

O que significa preenchido com bits zero

calloc define todos os bits como zero. Isso fornece valores zero para elementos inteiros e char. Portanto, um buffer de caracteres de tamanho positivo preenchido com zeros começa como uma cadeia vazia: seu primeiro caractere é '\0'.

Nas plataformas mais usadas, bits todos iguais a zero também representam zero de ponto flutuante e ponteiros nulos. C portável não garante essas representações para tipos de ponto flutuante e ponteiros. Se o código precisar desses valores em todas as implementações de C, atribua 0.0 ou NULL explicitamente aos elementos.

Escolha entre as funções de alocação

Uma chamada bem-sucedida a malloc seguida de memset pode preencher um bloco com zeros, mas a multiplicação do tamanho nesse código ainda precisa de uma proteção contra estouro. As implementações mais usadas de calloc rejeitam um produto grande demais para size_t; o C23 exige isso explicitamente. O resultado ainda precisa de uma verificação de ponteiro nulo, pois uma solicitação de tamanho correto pode falhar.

O preenchimento com zeros se aplica a essa alocação. Se realloc aumentar o bloco depois, os bytes adicionados não serão inicializados. Atribua valores a esses elementos antes de incrementá-los ou lê-los. Por fim, libere o bloco com free, como faria com um bloco obtido com malloc.

Um bloco alocado precisa de uma resposta clara para “Quem libera isto?”. Essa é a responsabilidade pela liberação. Outro código pode tomar o endereço emprestado sem receber permissão para liberá-lo.

Libere após o último uso

free, declarada em <stdlib.h>, torna um bloco alocado ainda válido disponível para reutilização. Passe seu endereço inicial exatamente uma vez. free(NULL) não faz nada. Passar um endereço local, um literal de cadeia de caracteres, um endereço interno como p + 1 ou um bloco já liberado causa comportamento indefinido.

free(p) não atribui um valor à variável p e não promete apagar os bytes. Após a liberação, o valor antigo do ponteiro é inválido. Se a variável continuar em uso, atribua p = NULL; sem examinar seu valor antigo. Isso altera apenas p; as referências alternativas ainda precisam deixar de usar o bloco liberado.

Uma função que retorna memória recém-alocada transfere a responsabilidade pela liberação à função chamadora:

#include <stdlib.h>
#include <string.h>

char *copy_string(const char *s) {
    char *copy = malloc(strlen(s) + 1);
    if (copy == NULL) return NULL;
    strcpy(copy, s);
    return copy;
}

A função chamadora verifica o resultado, usa a cópia e a libera. A cadeia de entrada é emprestada; essa função não a libera. POSIX e C23 oferecem strdup para o mesmo padrão de responsabilidade pela liberação; a função acima também funciona em C17.

Libere alocações aninhadas de dentro para fora

Uma grade feita de um arranjo de ponteiros para linhas tem blocos separados. Três ponteiros para linhas e três linhas de quatro valores int exigem quatro alocações. Com ponteiros de 8 bytes e valores int de 4 bytes, o bloco externo usa 24 bytes e as linhas usam 48 bytes, totalizando 72 bytes.

Libere cada linha enquanto seu endereço ainda estiver disponível e depois libere o arranjo de ponteiros. Liberar o bloco externo não libera recursivamente suas linhas. Acessar grid[i] após liberar grid usa armazenamento liberado.

Libere recursos após sucesso parcial

Este exemplo completo acompanha quantas linhas realmente existem:

#include <stdlib.h>

int main(void) {
    size_t rows = 3, made = 0;
    int **grid = malloc(rows * sizeof *grid);
    if (grid == NULL) return EXIT_FAILURE;

    for (; made < rows; ++made) {
        grid[made] = malloc(4 * sizeof *grid[made]);
        if (grid[made] == NULL) break;
    }
    int status = made == rows ? EXIT_SUCCESS : EXIT_FAILURE;
    /* Use the grid here only if every row was allocated. */
    for (size_t i = 0; i < made; ++i) free(grid[i]);
    free(grid);
    return status;
}

Se a segunda linha falhar, made será 1, então somente a linha zero será liberada. Nenhum ponteiro de linha não inicializado é lido. Outra solução útil inicializa ponteiros independentes com NULL e encaminha toda falha para uma única seção de liberação de recursos; free(NULL) torna essa seção segura após sucesso parcial.

Conte os tempos de responsabilidade pela liberação, não as chamadas de alocação. Um buffer criado por malloc e redimensionado com sucesso duas vezes precisa de uma chamada final a free aplicada ao resultado mais recente; uma chamada bem-sucedida a realloc já encerra o tempo de vida do bloco anterior. O alocador pode manter o espaço liberado para alocações posteriores, então um monitor do sistema não precisa mostrar uma queda imediata na memória do processo.

realloc altera o tamanho de um bloco alocado. Ela pode aumentar ou reduzir o armazenamento, e o endereço retornado pode mudar em ambos os casos. Inclua <stdlib.h> e trate sucesso e falha como eventos diferentes no tempo de vida.

O que permanece e o que muda

Quando um bloco cresce, o conteúdo existente é preservado até o tamanho antigo. Os bytes adicionados não são inicializados. Quando ele diminui, somente a parte inicial que cabe no novo tamanho é preservada. Um arranjo que contém 3, 1, 4 e 1 mantém esses quatro valores quando aumentado para seis valores int; os dois últimos elementos precisam receber valores antes do uso. Com valores int de 4 bytes, isso altera a solicitação de 16 para 24 bytes.

O alocador pode ampliar o bloco no próprio local ou alocar em outro lugar, copiar os bytes preservados e liberar o bloco antigo. Seu código deve funcionar com qualquer um dos resultados.

Receba o resultado em um ponteiro temporário

int *tmp = realloc(nums, 6 * sizeof *nums);
if (tmp == NULL) {
    /* nums still owns its original block. */
} else {
    nums = tmp;
    nums[4] = 5;
    nums[5] = 9;
}

Para essa solicitação de tamanho positivo, uma falha deixa o bloco original alocado e inalterado. O programa pode continuar a usá-lo ou liberá-lo antes de relatar a falha. Em caso de sucesso, a responsabilidade pela liberação passa para o bloco retornado. Atribua o novo resultado antes de acessar o arranjo redimensionado.

A atribuição direta nums = realloc(nums, bytes); perde essa proteção. Se a chamada falhar, ela sobrescreve o único endereço armazenado com NULL. A alocação antiga permanece reservada, mas o programa não pode mais liberá-la.

Ponteiros salvos para elementos devem ser reconstruídos

Suponha que o código salve int *selected = &nums[2];. Um redimensionamento bem-sucedido encerra o tempo de vida do objeto antigo, mesmo quando o endereço retornado por acaso é igual. selected é inválido após esse sucesso. Guarde o índice 2 durante o redimensionamento e depois calcule selected = &nums[2]; a partir do novo ponteiro, se esse índice ainda existir.

Não compare o ponteiro antigo com o resultado para decidir se as referências alternativas precisam ser atualizadas. Use o novo resultado em toda chamada bem-sucedida. Se a redução tiver removido o elemento selecionado, não haverá ponteiro para esse elemento a reconstruir.

Um exemplo completo de crescimento e liberação

#include <stdlib.h>

int main(void) {
    int *nums = malloc(4 * sizeof *nums);
    if (nums == NULL) return EXIT_FAILURE;
    for (size_t i = 0; i < 4; ++i) nums[i] = (int)i;

    int *tmp = realloc(nums, 6 * sizeof *nums);
    if (tmp == NULL) {
        free(nums);
        return EXIT_FAILURE;
    }
    nums = tmp;
    nums[4] = 4;
    nums[5] = 5;
    free(nums);
    return EXIT_SUCCESS;
}

Para uma quantidade variável, verifique a multiplicação por seu tamanho em bytes antes dessa chamada, assim como em malloc. Solicite bytes, não elementos: realloc(nums, 6) solicita seis bytes.

realloc(NULL, positive_size) se comporta como malloc, o que permite que um buffer vazio comece com um ponteiro nulo. Para liberar um buffer, chame free explicitamente. Evite redimensionar para tamanho zero: o comportamento histórico das bibliotecas varia, e redimensionar um bloco existente para zero é comportamento indefinido no C23. Arranjos locais e blocos já liberados não são alvos válidos de redimensionamento.

Um arranjo que pode crescer precisa de três informações de estado: seu ponteiro, seu comprimento e sua capacidade. O comprimento conta os elementos inicializados em uso. A capacidade conta as posições de elementos alocadas. Mantenha o comprimento menor ou igual à capacidade.

Acrescente em uma ordem segura

Comece com int *data = NULL; size_t len = 0, cap = 0;. Antes de uma inserção, verifique se len == cap. Um arranjo cheio deve crescer antes da escrita em data[len]. Somente após o sucesso do redimensionamento o ponteiro e a capacidade podem mudar. Armazene o novo valor e depois aumente o comprimento.

O exemplo completo a seguir acrescenta dez valores com crescimento geométrico:

#include <stdint.h>
#include <stdlib.h>

int main(void) {
    int *data = NULL;
    size_t len = 0, cap = 0;
    for (int value = 0; value < 10; ++value) {
        if (len == cap) {
            size_t next;
            if (cap == 0) {
                next = 4;
            } else {
                if (cap > SIZE_MAX / 2 / sizeof *data) {
                    free(data);
                    return EXIT_FAILURE;
                }
                next = cap * 2;
            }
            int *tmp = realloc(data, next * sizeof *data);
            if (tmp == NULL) {
                free(data);
                return EXIT_FAILURE;
            }
            data = tmp;
            cap = next;
        }
        data[len++] = value;
    }
    free(data);
    return EXIT_SUCCESS;
}

A proteção contra estouro verifica tanto a duplicação quanto a conversão para bytes antes que qualquer um dos produtos possa sofrer redução modular. A capacidade inicial de quatro também cabe nesse tipo de elemento. Em caso de falha, o programa libera a alocação antiga, pela qual ainda é responsável, e para; ele não atualiza incorretamente a capacidade.

Rastreie comprimento e capacidade separadamente

Começando com capacidade 4, as primeiras quatro inserções usam o espaço existente. Antes da quinta, a capacidade dobra para 8. Antes da nona, dobra para 16. Dez inserções terminam com comprimento 10 e capacidade 16. Se as duas operações de crescimento moverem o bloco, elas copiarão no máximo quatro e oito elementos, totalizando doze.

A capacidade livre é intencional. Crescer um elemento a cada inserção causa cópias repetidas. A partir da capacidade inicial 1, chegar a 1.000 elementos pode exigir 999 redimensionamentos e 499.500 elementos copiados. A duplicação chega à capacidade 1.024 após dez redimensionamentos e no máximo 1.023 cópias. Um redimensionamento específico pode ser custoso, mas o trabalho médio por inserção permanece constante com crescimento geométrico.

Um fator como 1,5 deixa menos espaço livre, mas cresce com mais frequência. Se a entrada tiver terminado, o programa pode reduzir o bloco ao comprimento em uso, tratando a falha com o mesmo padrão de ponteiro temporário. Um arranjo vazio é liberado com free, não com um redimensionamento para tamanho zero.

Buffers de caracteres precisam de uma posição adicional

Para uma cadeia que cresce, reserve espaço para '\0'. Antes de acrescentar um caractere, aumente o buffer se len + 1 >= cap. Com capacidade 8, cabem sete caracteres, deixando a posição do terminador; “hello world” provoca o crescimento para 16 e precisa de doze bytes, incluindo seu terminador.

Um ponteiro salvo para um elemento se torna inválido após um crescimento bem-sucedido. Guarde um índice e acesse novamente o elemento usando o novo endereço inicial. Ao redefinir um arranjo para uso posterior, libere seu bloco e defina data = NULL; len = cap = 0;.

Um vazamento de memória é um armazenamento alocado de que um programa não precisa mais, mas que nunca libera. Muitas vezes, o último ponteiro desaparece, tornando impossível uma chamada posterior a free. Um vazamento pode ocorrer silenciosamente enquanto o uso de memória cresce.

Rastreie endereços, não nomes de variáveis

char *p = malloc(100);
if (p == NULL) return EXIT_FAILURE;
p = malloc(200);  /* loses the only address of the first block */
if (p == NULL) return EXIT_FAILURE;
free(p);

A chamada final a free libera apenas o segundo bloco. O nome p foi reutilizado; a primeira alocação não foi. Se a segunda solicitação falhar, o bloco de 100 bytes ainda estará perdido. Libere o primeiro bloco antes de substituí-lo, quando ele não for mais necessário, ou guarde seu endereço em outra variável responsável por sua liberação.

Atribuir NULL a um ponteiro responsável antes de liberar o bloco causa a mesma perda. A atribuição altera uma variável ponteiro; não informa ao alocador que deve liberar algo. Variáveis locais automáticas desaparecem ao final de uma chamada, mas os blocos alocados para os quais apontavam permanecem.

Examine todas as saídas de uma função

Um retorno antecipado pode ignorar a liberação de recursos:

char *line = malloc(100);
if (line == NULL) return EXIT_FAILURE;
if (input_is_bad) {
    free(line);
    return EXIT_FAILURE;
}
/* Use line on the successful path. */
free(line);

Ambos os caminhos liberam o bloco. Em uma função com mais recursos, uma única seção de liberação reduz a quantidade de caminhos a examinar. Uma função que retorna um resultado alocado transfere a responsabilidade por sua liberação; uma função que apenas abandona um ponteiro local responsável causa um vazamento.

A atribuição direta do resultado de uma chamada malsucedida a realloc é outro caminho de perda. Alocações aninhadas vazam quando seu arranjo externo de ponteiros é liberado antes que os endereços internos sejam usados para liberar os recursos.

A repetição torna pequenos vazamentos custosos

Suponha que um laço aloque 100 bytes por passagem e nunca os libere. Após 1.000 passagens, ele terá abandonado 100.000 bytes. Libere cada buffer ao final de sua passagem ou aloque uma vez antes do laço, reutilize o bloco e libere-o depois. A reutilização também evita trabalho repetido do alocador quando a mesma capacidade é suficiente.

Um serviço que deixa vazar 64 bytes por solicitação perde 640.000 bytes após 10.000 solicitações, exatamente 625 KiB. Após um milhão de solicitações, terá perdido 64.000.000 bytes, cerca de 61 MiB. Programas de longa duração podem acabar falhando ao alocar memória ou deixando o sistema lento. O sistema operacional normalmente recupera a memória do processo ao término, mas isso não ajuda o serviço enquanto ele executa.

Perdida e ainda acessível são relatórios diferentes

Se um ponteiro global ainda contiver o endereço inicial de uma alocação ao término, o Valgrind classificará o bloco como “ainda acessível” (still reachable). O endereço não foi perdido; o programa simplesmente não liberou o bloco. “Definitivamente perdida” (definitely lost) significa que não resta nenhum ponteiro utilizável. Planeje a liberação de recursos para que esses relatórios mostrem claramente as alocações sem explicação.

Um ponteiro se torna pendente quando termina o tempo de vida do objeto para o qual ele aponta. A variável ainda pode existir, mas ler ou escrever o objeto antigo por meio desse ponteiro é inválido. Retornar um endereço local e liberar um bloco alocado podem criar esse problema.

Encontre o último uso antes da liberação

int *scores = malloc(3 * sizeof *scores);
if (scores == NULL) return EXIT_FAILURE;
scores[0] = 90;
scores[1] = 75;
scores[2] = 82;
free(scores);
printf("%d\n", scores[0]);  /* use-after-free */

A atribuição a scores[0] ocorreu durante o tempo de vida do bloco. A leitura final não. Mova free(scores) para depois da impressão, quando todos os usos estiverem concluídos. Apenas atribuir scores = NULL antes da impressão transforma o acesso inválido em uma desreferenciação de ponteiro nulo; isso não fornece os dados ausentes.

Isso é comportamento indefinido: C não impõe requisitos sobre o resultado. O programa pode exibir um valor antigo, encerrar inesperadamente ou danificar dados silenciosamente. Os bytes liberados frequentemente permanecem no local até que o alocador os reutilize. Portanto, um resultado plausível não valida uma leitura após a liberação.

Referências alternativas compartilham o problema de tempo de vida

int *a = malloc(3 * sizeof *a);
if (a == NULL) return EXIT_FAILURE;
int *b = a;
free(a);
a = NULL;
b[0] = 1;  /* b also lost its live target */

Havia um bloco, com duas variáveis ponteiro contendo seu endereço. Liberá-lo por meio de a encerra seu tempo de vida para ambos os ponteiros. Atribuir nulo a a altera apenas a; isso não pode atualizar b. O código que usa referências alternativas emprestadas deve terminar antes que o responsável libere o bloco, e essas referências não devem ser usadas depois.

A liberação dupla é outro uso após o fim do tempo de vida

Chamar free duas vezes para um bloco é uma liberação dupla, incluindo uma segunda chamada por meio de uma referência alternativa. Isso pode corromper os registros de controle do alocador ou fazer uma alocação posterior falhar. Algumas bibliotecas detectam o problema imediatamente e interrompem o programa, mas essa detecção imediata não é garantida.

Atribuir NULL à variável responsável após a liberação ajuda em uma chamada repetida de liberação, pois free(NULL) é válida. Isso não torna free(b) segura quando b ainda se refere ao bloco anterior. Exatamente um responsável deve decidir quando o bloco será liberado.

O redimensionamento também encerra o tempo de vida antigo

Uma chamada bem-sucedida a realloc substitui o objeto antigo mesmo que o endereço numérico retornado não mude. Ponteiros salvos para o interior do bloco antigo devem ser recalculados a partir do ponteiro retornado. Armazene posições como índices enquanto o crescimento puder ocorrer. Uma chamada malsucedida a realloc com tamanho positivo, por outro lado, mantém a alocação antiga válida.

Uma função que retorna o endereço de uma variável local automática cria um erro de tempo de vida semelhante sem chamar free: o objeto deixa de existir quando a função retorna. Use armazenamento de responsabilidade da função chamadora ou um resultado no heap com responsável definido. O uso após a liberação e a liberação dupla também podem se tornar defeitos de segurança quando um atacante pode influenciar o armazenamento reutilizado.

Um acesso válido a um elemento exige armazenamento suficiente e um valor atribuído antes da leitura. Um bloco pode ter o tamanho correto, mas conter dados não inicializados, ou conter valores úteis, mas ser acessado fora de seus limites.

Verifique a faixa de elementos

Para n elementos, os índices válidos vão de zero a n - 1. Um laço com i <= n realiza um acesso a mais. Com dez valores int de 4 bytes, a alocação é de 40 bytes; p[10] começa imediatamente após esses bytes. Use i < n para percorrer os dez elementos.

Um índice obtido da entrada também precisa de uma verificação de faixa antes do uso. Uma entrada com sinal deve ser não negativa e menor que a quantidade de elementos. Mantenha a quantidade junto ao ponteiro e passe ambos às funções. Um ponteiro sozinho não descreve a faixa permitida.

Dimensione cadeias de caracteres para seu terminador

char *copy = malloc(strlen(s));
strcpy(copy, s);  /* writes the terminator beyond the allocation */

Esse trecho incorreto também precisa de uma verificação de falha. A correção do tamanho é malloc(strlen(s) + 1), seguida da verificação e depois da cópia. “Amsterdam” tem nove caracteres, mas precisa de dez bytes com '\0'. O terminador é um byte realmente armazenado, embora não seja impresso como parte do texto.

Um arranjo de ponteiros não armazena as cadeias de caracteres

char **names = malloc(n * sizeof *names);

Isso reserva n posições para ponteiros. Não cria buffers de caracteres para esses ponteiros endereçarem. Antes de usar names[i] como uma cadeia de caracteres, atribua a ele um endereço válido de cadeia. Ele pode tomar emprestado um arranjo existente ou um literal com tempo de vida suficiente, ou ser responsável por uma cópia da cadeia alocada separadamente. Apenas as cadeias sob sua responsabilidade são liberadas durante a liberação dos blocos aninhados.

O mesmo raciocínio de tamanho se aplica a arranjos numéricos: malloc(n) conta bytes, e sizeof p mede um ponteiro. Use n * sizeof *p, com a proteção contra estouro e a verificação de ponteiro nulo, para expressar corretamente uma quantidade de elementos.

Escreva antes de ler

int *t = malloc(3 * sizeof *t);
if (t == NULL) return EXIT_FAILURE;
t[0] = 5;
t[1] = 7;
printf("%d\n", t[0] + t[1] + t[2]);  /* t[2] was never set */
free(t);

t[2] está dentro do bloco alocado, mas seu valor não foi inicializado. Atribua um valor a ele antes da soma ou use calloc quando zero for o valor inicial desejado. Os bytes adicionados durante o crescimento com realloc precisam da mesma atenção. Estar dentro dos limites não inicializa a memória.

Por que o encerramento inesperado pode ocorrer depois

Uma escrita fora dos limites pode danificar dados próximos ou os registros de controle do alocador. Uma leitura fora dos limites pode expor dados não relacionados. Ambas causam comportamento indefinido. Um pequeno acesso além dos limites pode atingir memória mapeada e escapar à detecção imediata; uma chamada posterior a free pode ser a primeira falha visível.

Verifique independentemente o tamanho da alocação, a faixa de índices e o histórico de inicialização. Uma alocação maior não pode fornecer um valor significativo a um elemento não inicializado, e preencher com zeros não pode tornar válido um índice fora da faixa.

Uma falha de segmentação é uma resposta do sistema operacional a um acesso proibido à memória. Causas comuns incluem desreferenciar um ponteiro nulo ou não inicializado, escrever em um literal de cadeia de caracteres, acessar muito além dos limites de um arranjo, usar armazenamento liberado e esgotar a pilha.

O que a mensagem informa

No Linux, SIGSEGV geralmente interrompe o processo, e um shell pode imprimir “Segmentation fault (core dumped)”. Um código de saída comum do shell é 139, pela convenção de sinais de 128 mais o sinal 11. O macOS pode relatar SIGSEGV ou SIGBUS para acessos inválidos. O Windows chama a falha equivalente de violação de acesso, frequentemente com o código de exceção 0xC0000005.

Essas mensagens identificam um acesso malsucedido, não seu histórico completo. Um pequeno acesso além dos limites pode corromper um ponteiro no início e causar um encerramento inesperado muito depois. Muitos acessos inválidos permanecem dentro da memória que o processo pode endereçar, então corrompem dados silenciosamente em vez de gerar uma falha.

Comece com informações de linha

Compile um executável para depuração com avisos:

cc -std=c17 -g -O0 -Wall -Wextra program.c -o program

Depois, execute-o em um depurador ou verificador de memória. Um rastreamento da pilha de chamadas lista as chamadas de função ativas no momento da falha. Encontre o registro de ativação mais acima que pertença ao seu próprio código. Funções de biblioteca como free podem ser o lugar onde um estado incorreto se torna visível, enquanto uma chamada anterior em seu programa o criou.

Na linha relatada, identifique cada ponteiro desreferenciado. Para cada um, rastreie seu valor até a origem. A alocação foi verificada? O objeto para o qual ele aponta ainda existe? O índice cabe no bloco? O ponteiro chegou a receber um endereço válido?

Analise um resultado nulo

int *p = NULL;
printf("%d\n", *p);  /* invalid dereference */

A impressão exige uma leitura por meio de p, mas não existe um objeto inteiro nesse endereço. Se p veio de uma função de alocação, verifique o resultado antes dessa linha e siga um caminho de erro em caso de falha. Se recebeu nulo após a liberação, mova o uso necessário para antes da liberação ou repense onde os dados são armazenados.

Um ponteiro não inicializado, como em int *p; *p = 5;, não recebeu um objeto válido para o qual apontar. Uma alocação, o endereço de um objeto ainda válido ou um ponteiro emprestado verificado deve estabelecer esse objeto antes da desreferenciação.

Acompanhe a causa quando os sintomas mudarem

Uma função recursiva infinita pode esgotar os registros de ativação da pilha em uma versão sem otimização. Uma condição de parada corrige a lógica. Um compilador com otimização pode transformar algumas chamadas recursivas em um laço, então a ausência de um encerramento por estouro de pilha não torna útil o cálculo sem limite.

Mensagens impressas de progresso também são evidências imperfeitas. stdout é armazenada em buffer: a saída pode não ser gravada quando um processo encerra inesperadamente, especialmente com saída redirecionada. Para uma mensagem de diagnóstico, use stderr ou chame fflush(stdout) após uma impressão de progresso. Acrescentar uma impressão pode alterar a disposição da memória e esconder um erro; isso não corrigiu o acesso inválido. Execute novamente com um verificador para encontrar a própria operação com defeito.

A ferramenta padrão do Valgrind, o Memcheck, observa um programa compilado durante sua execução. Ela acompanha os limites do heap, os tempos de vida das alocações e se os valores foram inicializados. Não precisa de uma compilação com sanitizador, mas as informações de depuração tornam seus relatórios muito mais fáceis de usar.

Compile e execute

cc -std=c17 -g -O0 -Wall -Wextra program.c -o program
valgrind --leak-check=full ./program

Coloque os argumentos do próprio programa após ./program. Acrescente --show-leak-kinds=all para listar todas as categorias de vazamento e --track-origins=yes quando a origem de um valor não inicializado não estiver clara.

O Valgrind executa no Linux e em alguns outros sistemas semelhantes ao Unix, mas não nativamente no Windows ou em Macs com Apple silicon. O Memcheck frequentemente torna a execução aproximadamente 20 a 30 vezes mais lenta. Use primeiro uma pequena entrada que reproduza o problema e depois execute outros testes. Um teste sem erros cobre apenas os caminhos que realmente executa.

Leia o tamanho do acesso e o tamanho do bloco separadamente

Um relatório com o cabeçalho “Invalid write of size 4” descreve uma escrita de quatro bytes. Um endereço descrito como “0 bytes after a block of size 40 alloc'd” começa imediatamente após uma alocação de 40 bytes. Se esse bloco contiver dez valores int de 4 bytes, o acesso inválido começa no elemento 10; o último elemento válido é o 9.

O relatório também indica a linha do acesso e a pilha de chamadas da alocação. Use-os em conjunto: a alocação informa os limites pretendidos, e o acesso informa qual índice os violou. “Size 4” não significa que o programa ultrapassou o limite em quatro elementos.

“Invalid read of size N” descreve, da mesma forma, uma leitura inválida. Um endereço dentro de um bloco descrito como “free'd” indica um problema de tempo de vida; compare os locais de alocação, liberação e acesso. “Invalid free() / delete / delete[] / realloc()” pode indicar uma liberação duplicada ou um endereço que nunca foi o início de uma alocação válida.

Para uma condição que usa dados sem valor atribuído, o Memcheck pode informar “Conditional jump or move depends on uninitialised value(s)”. Essa grafia pertence à mensagem da ferramenta. A condição relatada consumiu o valor; --track-origins=yes ajuda a localizar a origem do armazenamento não inicializado.

Leia a categoria do vazamento

Suponha que uma função auxiliar aloque dez valores int de 4 bytes em um ponteiro local e retorne sem liberar ou retornar o endereço. Seu bloco de 40 bytes está definitivamente perdido. Um ponteiro global que mantivesse o endereço inicial faria com que um bloco não liberado fosse classificado como ainda acessível. Os totais de alocações e liberações do resumo do heap descrevem eventos, incluindo redimensionamentos; eles não substituem o raciocínio sobre responsabilidade pela liberação.

Um término sem erros pode apresentar “All heap blocks were freed -- no leaks are possible” e “ERROR SUMMARY: 0 errors from 0 contexts”. O Memcheck geralmente não detecta todo acesso além dos limites de arranjos locais ou globais que permaneça em memória válida. Corrija o primeiro erro relatado, execute novamente e teste outras entradas, incluindo entrada vazia e caminhos com retorno antecipado.

O AddressSanitizer, ou ASan, acrescenta verificações de acesso à memória durante a compilação. O executável resultante verifica a si próprio durante a execução. Ele é útil para testes rotineiros de desenvolvimento, pois normalmente torna a execução cerca de duas vezes mais lenta, muito menos que o Memcheck.

Compile e faça a ligação com o sanitizador

cc -std=c17 -g -fsanitize=address -fno-omit-frame-pointer \
    program.c -o program-asan
./program-asan

Use a opção do sanitizador tanto na compilação quanto na ligação final ao executar essas etapas separadamente. -g fornece informações de linha, e -fno-omit-frame-pointer ajuda a preservar pilhas de chamadas úteis. O compilador da Microsoft usa /fsanitize=address.

O ASan detecta acessos além dos limites de arranjos no heap, na pilha e globais, uso após a liberação, liberações inválidas e liberações duplas. Verificações do tempo de vida no escopo e verificações opcionais de uso após o retorno também podem detectar ponteiros para antigas variáveis locais. Ele exige recompilação e memória adicional. Mantenha essa instrumentação nas versões de desenvolvimento e teste.

Leia os três históricos

Um relatório de uso após a liberação pode começar com “ERROR: AddressSanitizer: heap-use-after-free”. A mensagem seguinte, “READ of size 4”, descreve a operação inválida. O relatório mostra então onde a memória foi “freed by thread T0 here:” e “previously allocated by thread T0 here:”.

Comece pela primeira linha relevante em seu código em cada pilha de chamadas. A alocação estabelece o bloco; a liberação encerra seu tempo de vida; a leitura relatada ocorre depois desse encerramento. Decida se deve mover a liberação para depois da leitura ou parar de acessar o bloco após a liberação. O relatório fornece o histórico, enquanto a responsabilidade pretendida pela liberação determina a correção.

Para “heap-buffer-overflow”, um endereço descrito como “located 0 bytes after 20-byte region” começa imediatamente após a região. Converta bytes em elementos somente depois de verificar o tamanho do tipo usado pelo programa. O ASan normalmente para no primeiro erro, então corrigi-lo pode revelar outro erro na próxima execução.

Verificações de vazamento e valores não inicializados são diferentes

O LeakSanitizer verifica alocações não liberadas ao término. Ele normalmente é ativado com o ASan no Linux. Em cadeias de ferramentas compatíveis do macOS, pode ser ativado com ASAN_OPTIONS=detect_leaks=1; algumas cadeias de ferramentas para Mac não o oferecem. A ferramenta separada leaks da Apple é outra opção de verificação de vazamentos nesses casos.

O ASan não acompanha se um valor dentro dos limites foi inicializado. Para esse problema, use o Memcheck ou o MemorySanitizer do Clang em uma configuração Linux compatível. O UndefinedBehaviorSanitizer verifica outros tipos de comportamento indefinido, como estouro de inteiro com sinal, e pode ser combinado com o ASan usando -fsanitize=address,undefined.

Escolha uma execução separada para cada verificador

Não execute um executável com ASan no Valgrind. Compile um executável comum separado para depuração com o Memcheck e não combine ASan e MemorySanitizer em uma mesma compilação. Após uma execução sem erros, varie a entrada para que outros caminhos de alocação, crescimento e liberação sejam executados.

Um relatório de memória identifica um erro observado e partes de seu histórico. Uma correção útil restaura o tamanho, os limites, a inicialização e a responsabilidade pela liberação corretos e depois verifica novamente o programa corrigido.

Reduza e reproduza

Encontre a menor entrada que ainda produza o erro. Compile com -g, avisos e pouca otimização e depois use o Memcheck ou uma versão com ASan. Leia o primeiro relatório antes de investigar os posteriores; um estado corrompido pode gerar uma cadeia de falhas enganosas.

Suponha que um programa contenha:

size_t n = 5;
int *v = malloc(n * sizeof *v);
for (size_t i = 0; i <= n; ++i) v[i] = (int)(i * i);
printf("%d\n", v[2]);
return 0;

Em um sistema com valores int de 4 bytes, o ASan relata uma escrita de quatro bytes no primeiro byte após uma alocação de 20 bytes. A escrita está no laço. O Memcheck também pode relatar o acesso além dos limites e, depois, uma alocação não liberada; se o bloco está perdido ou ainda acessível depende de quais ponteiros permanecem ao término.

Relacione o relatório ao código

Cinco valores int ocupam os índices de zero a quatro. A condição i <= n alcança o índice cinco. O tamanho da alocação está correto; o limite do laço não está. Aumentar o bloco esconderia o sintoma, mas deixaria o percurso incorreto.

Também não há verificação da alocação, e o bloco sob responsabilidade do programa não é liberado. Esses problemas exigem suas próprias correções, mesmo que o primeiro relatório tenha interrompido o programa antes de alcançá-los.

#include <stdio.h>
#include <stdlib.h>

int main(void) {
    size_t n = 5;
    int *v = malloc(n * sizeof *v);
    if (v == NULL) return EXIT_FAILURE;
    for (size_t i = 0; i < n; ++i) v[i] = (int)(i * i);
    printf("%d\n", v[2]);
    free(v);
    return EXIT_SUCCESS;
}

O programa corrigido inicializa cinco elementos válidos, imprime 4 enquanto o bloco ainda existe e o libera. A pequena quantidade fixa cabe no tipo; uma quantidade obtida da entrada também precisa da verificação de estouro no cálculo do tamanho antes da alocação.

Use o histórico do relatório para fazer a correção adequada

Para uso após a liberação, compare as pilhas de liberação e acesso para encontrar o último uso legítimo. Mova a liberação para depois dele ou remova o acesso inválido posterior. Atribuir NULL a um ponteiro não pode tornar seus dados anteriores disponíveis novamente.

Para um vazamento, a pilha de alocação informa onde o bloco começou. Ela não identifica a linha correta para a liberação. Rastreie a responsabilidade pela liberação nos retornos bem-sucedidos e nas falhas para encontrar onde termina o último uso. Para uma liberação dupla, remova a liberação duplicada ou corrija os responsáveis conflitantes. Remover a única liberação válida cria um vazamento.

Para dados não inicializados, acrescente --track-origins=yes ao Memcheck. A linha que consome os dados pode estar longe da alocação que forneceu bytes sem valores definidos. Inicialize cada valor lido pelo cálculo ou use calloc quando zero for o estado inicial correto.

Verifique a correção em mais de um caminho

Recompile e execute novamente a entrada original que reproduzia o problema. Continue até que seu relatório não apresente erros e depois tente entrada vazia, limites de crescimento, entrada comum e retornos por erro. Os avisos do compilador detectam alguns problemas antes da execução; ferramentas de execução verificam os caminhos alcançados por esses testes.