Que se passe-t-il lorsque la pile et le tas entrent en collision ?

Question

Je suis curieux de savoir ce qui se passe lorsque la pile et le tas entrent en collision. Si quelqu'un a déjà rencontré ce problème, il peut m'expliquer le scénario.

Answer 1

Dans un langage moderne fonctionnant sur un système d'exploitation moderne, vous obtiendrez soit un débordement de pile (hourra !), soit un message d'erreur. malloc() o sbrk() o mmap() échouera quand vous essayerez de faire croître le tas. Mais tous les logiciels ne sont pas modernes, alors examinons les modes d'échec :

• Si la pile se développe dans le tas, le compilateur typiquement C commencera silencieusement à écraser les structures de données du tas. Sur un système d'exploitation moderne, il existe une ou plusieurs mémoires virtuelles. pages de garde qui empêchent la pile de croître indéfiniment. Tant que la quantité de mémoire dans les pages de garde est au moins aussi grande que la taille de l'enregistrement d'activation de la procédure en croissance, le système d'exploitation vous garantit un défaut de segmentation. Si vous êtes un DOS fonctionnant sur une machine sans MMU, vous êtes probablement fichu.

• Si le tas s'étend sur la pile, le système d'exploitation doit toujours être conscient de la situation et une sorte d'appel système échouera. L'implémentation de malloc() remarque presque certainement l'échec et retourne NULL . Ce qui se passe ensuite dépend de vous.

Je suis toujours étonné par la volonté des auteurs de compilateurs d'espérer que le système d'exploitation mette en place des pages de garde pour éviter les débordements de pile. Bien sûr, cette astuce fonctionne bien jusqu'à ce que vous commenciez à avoir des milliers de threads, chacun avec sa propre pile...

Answer 2

Cela dépendrait de la plate-forme. Sur de nombreuses plateformes, cela ne peut pas se produire du tout (le tas et la pile sont alloués dans des pages différentes et les deux ne se rencontreront jamais).

Gardez à l'esprit que l'idée de la croissance du tas vers le haut et de la pile vers le bas n'est que conceptuelle. Sur les très petits systèmes (comme les anciens micros 8 bits qui exécutaient CP/M) et sur certains PIC et autres systèmes à modèle de mémoire plat (ceux qui n'ont pas de MMU ni aucun autre support de mémoire virtuelle ou protégée), le tas et la pile pourraient être réellement implémentés de cette façon. Dans ce cas, le comportement serait indéfini ... mais il y aurait presque certainement un crash dès que le code essaierait de retourner à une adresse au sommet de la pile corrompue ou de suivre un pointeur indirect d'une partie du tas à une autre ou ...

En tout cas, vous ne le verrez pas sur une station de travail ou un serveur moderne à usage général. Vous atteindrez une limite de ressources et obtiendrez des échecs de mallocs, ou vous vous heurterez à la mémoire virtuelle et le système finira par se transformer en un tas tremblant de "hit the red switch".

Answer 3

Dans des moments comme ceux-là, il est temps de se tourner vers les sages paroles du Dr Egon Spengler.....

• Dr. Egon Spengler : Il y a quelque chose de très important que j'ai oublié de vous dire.
• Dr. Peter Venkman : Quoi ?
• Dr. Egon Spengler : Ne laissez pas le tas entrer en collision avec la pile.
• Dr. Peter Venkman : Pourquoi ?
• Dr. Egon Spengler : Ce serait mauvais.
• Dr. Peter Venkman : Je suis un peu confus sur l'ensemble "bon/mauvais" chose ici. Qu'est-ce que vous voulez dire, "mauvais" ?
• Dr. Egon Spengler : Essayez d'imaginer que toute vie telle que vous la connaissez s'arrête instantanément et que chaque molécule de votre corps explose à la vitesse de la lumière.
• Dr. Ray Stantz : Inversion protonique totale !
• Dr. Peter Venkman : C'est mauvais. Ok. Très bien, conseil de sécurité important. Merci, Egon.

Answer 4

Si vous avez de la chance, vous obtenez une exception de mémoire ou de pile. Si vous êtes malchanceux, le programme se dirige vers une mémoire invalide et lève une exception de mauvaise mémoire. Si vous êtes extrêmement malchanceux, le programme continue et détruit quelque chose qu'il ne devrait pas et vous ne saurez jamais pourquoi votre programme a échoué.

Enfin, bien sûr, l'univers peut se fissurer.

Answer 5

Vous obtiendrez un défaut de segmentation ou une erreur d'allocation de mémoire si un dépassement de pile/heap se produit. Voici un exemple :

void recursiveFun ()
{
    static int i;
//  char *str= (char *)malloc (100);
    printf ("%d\t", i++);
    recursiveFun ();
// free (str);
}

Supposons que vous appelez la fonction ci-dessus, il n'y aura plus de pile et le programme se plantera. Maintenant, supprimez les lignes commentées et appelez la fonction à nouveau, vous constaterez que le défaut de segmentation se produit en moins de temps et moins de récursion que la version précédente. [ Dans mon environnement de test, le Stack Overflow s'est produit après 5237765 récursions dans le premier cas, alors que dans le second scénario, il s'est produit après 2616325 récursions].