Qu'est-ce que «l'expansion automatique de la pile»?

getrlimit (2) a la définition suivante dans les pages de manuel:

RLIMIT_AS La taille maximale de la mémoire virtuelle du processus (espace d'adressage) en octets. Cette limite affecte les appels à brk (2), mmap (2) et mremap (2), qui échouent avec l'erreur ENOMEM lors du dépassement de cette limite. L' expansion automatique de la pile échouera également (et générera un SIGSEGV qui tue le processus si aucune autre pile n'a été mise à disposition via sigaltstack (2)). Étant donné que la valeur est longue, sur les machines de 32 bits, cette limite est au maximum de 2 Gio ou cette ressource est illimitée.

Qu'entend-on ici par "expansion automatique de la pile"? La pile dans un environnement Linux / UNIX croît-elle au besoin? Si oui, quel est le mécanisme exact?

Oui, les piles se développent dynamiquement. La pile se trouve en haut de la mémoire et descend vers le tas.

--------------
| Stack      |
--------------
| Free memory|
--------------
| Heap       |
--------------
     .
     .

Le tas se développe vers le haut (chaque fois que vous faites malloc) et la pile se développe vers le bas au fur et à mesure que de nouvelles fonctions sont appelées. Le tas est présent juste au-dessus de la section BSS du programme. Ce qui signifie que la taille de votre programme et la façon dont il alloue de la mémoire en tas affectent également la taille maximale de la pile pour ce processus. Habituellement, la taille de la pile est illimitée (jusqu'à ce que les zones de tas et de pile se rencontrent et / ou écrasent, ce qui donnera un débordement de pile et SIGSEGV :-)

Ceci est uniquement pour les processus utilisateur, la pile du noyau est toujours fixe (généralement 8 Ko)

Le mécanisme exact est donné ici, sous Linux: lors de la gestion d'un défaut de page sur des mappages anonymes, vous vérifiez si c'est une "allocation de développement" que vous devez développer comme une pile. Si l'enregistrement de zone VM indique que vous devez, vous ajustez l'adresse de début pour étendre la pile.

Lorsqu'un défaut de page se produit, en fonction de l'adresse, il peut être réparé (et le défaut annulé) via l'extension de la pile. Ce comportement "croissant vers le bas en cas d'erreur" pour la mémoire virtuelle peut être demandé par des programmes utilisateur arbitraires avec l' MAP_GROWSDOWNindicateur transmis à l' mmapappel système.

Vous pouvez également jouer avec ce mécanisme dans un programme utilisateur:

#include <assert.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/mman.h>

int main() {
        long page_size = sysconf(_SC_PAGE_SIZE);
        void *mem = mmap(NULL, page_size, PROT_READ|PROT_WRITE, MAP_GROWSDOWN|MAP_ANONYMOUS|MAP_PRIVATE, -1, 0);
        if (MAP_FAILED == mem) {
                perror("failed to create growsdown mapping");
                return EXIT_FAILURE;
        }

        volatile char *tos = (char *) mem + page_size;

        int i;
        for (i = 1; i < 10 * page_size; ++i)
                tos[-i] = 42;

        fprintf(stderr, "inspect mappping for originally page-sized %p in /proc... press any key to continue...\n", mem);
        (void) getchar();

        if (munmap(mem, page_size))
                perror("failed munmap");

        return EXIT_SUCCESS;
}

Quand il vous invite, vous trouverez le pid du programme (via ps) et regardez /proc/$THAT_PID/mapspour voir comment la zone d'origine a augmenté.