5  Améliorations de nos bibliothèques d’allocation mémoire

Sont ici proposées des améliorations possibles applicables à nos différentes versions de bibliothèques d’allocation mémoire.

Le but de ces améliorations est d’optimiser l’implémentation, de détecter, autant que faire se peut, les utilisations illégales des blocs ou zones mémoire alloués dynamiquement.

5.1  Quelles améliorations ?

Une bibliothèque peut par exemple proposer, détecter ou empêcher :

1. Le passage à free() d’une adresse ne correspondant pas à une adresse précédemment retournée par malloc() ; ou de multiples appels à free() avec une même valeur de paramètre (libération multiple).
2. Le fait que l’utilisateur suppose le remplissage à zéro des zones mémoire retournées par malloc().
3. Le débordement d’écriture sur une zone mémoire allouée par malloc().
4. L’utilisation d’une zone mémoire après l’avoir rendue par free().
5. La fusion de zone mémoire libres contiguës et ainsi éviter une fragmentation de la mémoire.

Une bibliothèque peut aussi intégrer des outils permettant de faciliter la mise au point d’une application en ce qui concerne l’allocation dynamique de mémoire. Et par exemple proposer

1. La vérification du chaînage des blocs gérés par la bibliothèque.
2. La production d’une carte mémoire du tas. Le tas désignant l’ensemble des zones mémoire gérées par la bibliothèque d’allocation dynamique. Cela permet par exemple de détecter de possibles fuites de mémoire : allocation de zone mémoire jamais rendues par free().

5.2  Quelle implémentation de ces améliorations

Quelques pistes pour la mise en œuvre des propositions précédentes sont données ici.

1. Afin que free() puisse vérifier qu’une adresse qui lui est passée correspond effectivement à une adresse préalablement retournée par malloc(), nous pouvons :
   • garder une liste de ces adresses (bof) ; ou
   • lors de l’appel à malloc(), allouer un entête devant la zone mémoire qui sera retournée et marquer cette entête avec une valeur donnée ; lors du la libération de la zone via free(), on vérifie que le marqueur écrit dans l’entête a bien la valeur attendue.
   Détecter de multiples appels à free() avec une même adresse peut reposer sur la même idée d’un marqueur donné dans l’entête d’une zone mémoire déjà libérée.
2. Pour détecter les codes qui supposent que les zones mémoire retournées par malloc() sont mise à zéro, il peut suffire de remplir ces zones par des valeurs non-nulles ; l’exécution du code devrait impliquer une erreur qui nous espérons pourra être découverte par le programmeur.
3. Pour détecter les débordements d’écriture sur une zone mémoire allouée par malloc(), une solution consiste à allouer des zones de taille plus grande que demandée et de remplir cet espace par des valeurs arbitraires choisies. Lors de la remise de la zone à free(), on vérifie que cet emplacement n’a pas été écrit.
4. Pour éviter que le programmeur n’utilise encore une zone après l’avoir rendue par free(), nous pouvons réécrire par des valeurs arbitraires toutes les zones rendues.
5. La fusion de zones mémoire adjacentes peut être réalisée lors de chaque appel à free() ou par un appel spécifique de la bibliothèque.

   Maintenir la liste des zones libre dans l’odre croissant des adresses peut aider.

6. Lors de chaque appel à notre bibliothèque ou par des appels spécifiques à une fonction supplémentaire, nous pouvons vérifier l’intégrité du chaînage des blocs et donc vérifier que des écritures intempestives n’auraient pas détruites des informations.
7. Une autre fonction de notre bibliothèque pourrait produire un affichage de l’ensemble des informations concernant les zones alloués par malloc().