O que a chamada do sistema brk () faz?

De acordo com o manual do programador Linux:

brk () e sbrk () alteram o local da interrupção do programa, que define o final do segmento de dados do processo.

O que o segmento de dados significa aqui? É apenas o segmento de dados ou dados, BSS e heap combinados?

De acordo com o wiki:

Às vezes, os dados, o BSS e as áreas de heap são coletivamente chamados de "segmento de dados".

Não vejo razão para alterar o tamanho apenas do segmento de dados. Se forem dados, BSS e heap coletivamente, faz sentido, pois o heap terá mais espaço.

O que me leva à minha segunda pergunta. Em todos os artigos que li até agora, o autor diz que a pilha cresce para cima e a pilha para baixo. Mas o que eles não explicam é o que acontece quando o heap ocupa todo o espaço entre o heap e a pilha?

No diagrama que você postou, a "quebra" - o endereço manipulado por brke sbrk- é a linha pontilhada na parte superior da pilha.

A documentação que você leu descreve isso como o final do "segmento de dados" porque no mmapUnix tradicional (bibliotecas pré-compartilhadas, pré- ) o segmento de dados era contínuo com a pilha; antes do início do programa, o kernel carregava os blocos "texto" e "dados" na RAM, começando no endereço zero (na verdade, um pouco acima do endereço zero, de modo que o ponteiro NULL realmente não apontava para nada) e configurava o endereço de interrupção como o fim do segmento de dados. A primeira chamada para mallocentão seria usada sbrkpara mover a divisão e criar o heap entre a parte superior do segmento de dados e o novo endereço de interrupção mais alto, como mostrado no diagrama, e o uso subsequente de mallocusá-lo para aumentar o heap como necessário.

Enquanto isso, a pilha começa no topo da memória e cresce. A pilha não precisa de chamadas explícitas do sistema para aumentá-la; ou ele começa com o máximo de RAM alocado possível (essa era a abordagem tradicional) ou há uma região de endereços reservados abaixo da pilha, na qual o kernel aloca automaticamente a RAM quando nota uma tentativa de escrever nele (esta é a abordagem moderna). De qualquer forma, pode ou não haver uma região de "guarda" na parte inferior do espaço de endereço que pode ser usada para a pilha. Se essa região existe (todos os sistemas modernos fazem isso), ela é permanentemente mapeada; se quera pilha ou a pilha tenta crescer nela, você recebe uma falha de segmentação. Tradicionalmente, porém, o kernel não fez nenhuma tentativa de impor um limite; a pilha pode crescer na pilha, ou a pilha pode crescer na pilha, e de qualquer maneira eles escreviam sobre os dados uns dos outros e o programa travava. Se você tivesse muita sorte, ele falharia imediatamente.

Não sei de onde vem o número de 512 GB neste diagrama. Isso implica em um espaço de endereço virtual de 64 bits, que é inconsistente com o mapa de memória muito simples que você possui lá. Um espaço de endereço real de 64 bits se parece mais com isso:

              Legend:  t: text, d: data, b: BSS

Isso não é remotamente escalável, e não deve ser interpretado como exatamente como qualquer sistema operacional faz as coisas (depois que o desenhei, descobri que o Linux realmente coloca o executável muito mais próximo do endereço zero do que eu pensava, e as bibliotecas compartilhadas em endereços surpreendentemente altos). As regiões negras deste diagrama não são mapeadas - qualquer acesso causa um segfault imediato - e são gigantescas em relação às áreas cinzentas. As regiões cinza claro são o programa e suas bibliotecas compartilhadas (pode haver dezenas de bibliotecas compartilhadas); cada um tem um independentesegmento de texto e dados (e segmento "bss", que também contém dados globais, mas é inicializado com todos os bits zero, em vez de ocupar espaço no executável ou na biblioteca em disco). A pilha não é mais necessariamente contínua com o segmento de dados do executável - eu desenhei dessa maneira, mas parece que o Linux, pelo menos, não faz isso. A pilha não está mais vinculada à parte superior do espaço de endereço virtual e a distância entre o heap e a pilha é tão grande que você não precisa se preocupar em atravessá-la.

A quebra ainda é o limite superior da pilha. No entanto, o que eu não mostrei é que poderia haver dezenas de alocações independentes de memória no escuro em algum lugar, feitas com e mmapnão brk. (O sistema operacional tentará mantê-los longe da brkárea para que não colidam.)

Exemplo mínimo executável

O que a chamada do sistema brk () faz?

Solicita que o kernel permita que você leia e grave em um pedaço de memória contíguo chamado heap.

Se você não perguntar, isso pode ser um defeito.

Sem brk:

#define _GNU_SOURCE
#include <unistd.h>

int main(void) {
    /* Get the first address beyond the end of the heap. */
    void *b = sbrk(0);
    int *p = (int *)b;
    /* May segfault because it is outside of the heap. */
    *p = 1;
    return 0;
}

Com brk:

#define _GNU_SOURCE
#include <assert.h>
#include <unistd.h>

int main(void) {
    void *b = sbrk(0);
    int *p = (int *)b;

    /* Move it 2 ints forward */
    brk(p + 2);

    /* Use the ints. */
    *p = 1;
    *(p + 1) = 2;
    assert(*p == 1);
    assert(*(p + 1) == 2);

    /* Deallocate back. */
    brk(b);

    return 0;
}

GitHub upstream .

O exemplo acima pode não chegar a uma nova página e não segfault, mesmo sem o brk, então aqui está uma versão mais agressiva que aloca 16MiB e é muito provável que segfault sem o brk:

#define _GNU_SOURCE
#include <assert.h>
#include <unistd.h>

int main(void) {
    void *b;
    char *p, *end;

    b = sbrk(0);
    p = (char *)b;
    end = p + 0x1000000;
    brk(end);
    while (p < end) {
        *(p++) = 1;
    }
    brk(b);
    return 0;
}

Testado no Ubuntu 18.04.

Visualização do espaço de endereço virtual

Antes brk:

+------+ <-- Heap Start == Heap End

Depois brk(p + 2):

+------+ <-- Heap Start + 2 * sizof(int) == Heap End 
|      |
| You can now write your ints
| in this memory area.
|      |
+------+ <-- Heap Start

Depois brk(b):

+------+ <-- Heap Start == Heap End

Para entender melhor os espaços de endereço, familiarize-se com a paginação: Como funciona a paginação x86? .

Por que precisamos de ambos brke sbrk?

brkclaro que poderia ser implementado com sbrkcálculos de deslocamento, ambos existem apenas por conveniência.

No back-end, o kernel do Linux v5.0 possui uma única chamada do sistema brkusada para implementar os dois: https://github.com/torvalds/linux/blob/v5.0/arch/x86/entry/syscalls/syscall_64. tbl # L23

12  common  brk         __x64_sys_brk

É brkPOSIX?

brkcostumava ser POSIX, mas foi removido no POSIX 2001, portanto, a necessidade de _GNU_SOURCEacessar o wrapper glibc.

A remoção provavelmente ocorre devido à introdução mmap, que é um superconjunto que permite que vários intervalos sejam alocados e mais opções de alocação.

Eu acho que não há um caso válido em que você deva usar em brkvez de mallocou mmaphoje em dia.

brk vs malloc

brké uma antiga possibilidade de implementação malloc.

mmapé o novo mecanismo estritamente mais poderoso que provavelmente todos os sistemas POSIX usam atualmente para implementar malloc. Aqui está um exemplo mínimo de mmapalocação de memória executável .

Posso misturar brke malloc?

Se o seu mallocfor implementado brk, não tenho idéia de como isso não pode explodir as coisas, pois brkgerencia apenas um único intervalo de memória.

No entanto, não consegui encontrar nada sobre isso nos documentos da glibc, por exemplo:

• https://www.gnu.org/software/libc/manual/html_mono/libc.html#Resizing-the-Data-Segment

As coisas provavelmente funcionarão lá, suponho, uma vez que provavelmente serão mmapusadas malloc.

Veja também:

• O que é inseguro / legado sobre brk / sbrk?
• Por que chamar sbrk (0) duas vezes fornece um valor diferente?

Mais informações

Internamente, o kernel decide se o processo pode ter tanta memória e marca as páginas de memória para esse uso.

Isso explica como a pilha se compara à pilha: Qual é a função das instruções push / pop usadas nos registradores no assembly x86?

Você pode usar brke sbrk-se para evitar a "sobrecarga malloc" todo mundo está sempre reclamando. Mas você não pode usar esse método facilmente em conjunto com, mallocpor isso é apropriado apenas quando você não precisa fazer freenada. Porque você não pode. Além disso, você deve evitar chamadas de biblioteca que possam ser usadas mallocinternamente. Ou seja. strlenprovavelmente é seguro, mas fopenprovavelmente não é.

Ligue sbrkcomo você chamaria malloc. Ele retorna um ponteiro para a interrupção atual e incrementa a interrupção nesse valor.

void *myallocate(int n){
    return sbrk(n);
}

Embora não seja possível liberar alocações individuais (porque não há sobrecarga de malloc , lembre-se), você pode liberar todo o espaço chamando brkcom o valor retornado pela primeira chamada para sbrk, rebobinando assim o brk .

void *memorypool;
void initmemorypool(void){
    memorypool = sbrk(0);
}
void resetmemorypool(void){
    brk(memorypool);
}

Você pode até empilhar essas regiões, descartando a região mais recente, rebobinando a interrupção no início da região.

Mais uma coisa ...

sbrktambém é útil no código de golfe, pois é 2 caracteres menor que malloc.

Há um mapeamento de memória privada anônima designado especial (tradicionalmente localizado logo além dos dados / bss, mas o Linux moderno realmente ajustará o local com o ASLR). Em princípio, não é melhor do que qualquer outro mapeamento você poderia criar com é mmap, mas o Linux tem algumas otimizações que tornam possível para expandir o final deste mapeamento (usando o brksyscall) para cima com bloqueio custo reduzido em relação ao que mmapou mremapincorreria. Isso torna atraente o mallocuso das implementações ao implementar o heap principal.

Eu posso responder sua segunda pergunta. Malloc falhará e retornará um ponteiro nulo. É por isso que você sempre procura um ponteiro nulo ao alocar dinamicamente a memória.

A pilha é colocada por último no segmento de dados do programa. brk()é usado para alterar (expandir) o tamanho do heap. Quando o heap não puder crescer mais, qualquer mallocchamada falhará.

O segmento de dados é a parte da memória que contém todos os seus dados estáticos, lidos no executável na inicialização e geralmente preenchidos com zero.

O malloc usa a chamada do sistema brk para alocar memória.

incluir

int main(void){

char *a = malloc(10); 
return 0;
}

executar este programa simples com strace, ele chamará o sistema brk.