Posté par neologix .
En réponse au journal realloc.
Évalué à 5.
Comme expliqué ci-dessus, dans ce cas il n'y aura pas de fuite mémoire, en cas d'OOM ça finit soit avec le OOM killer soit en segfault.
Mais realloc() a une particularité intéressante qui rend facile l'introduction d'une fragmentation du tas : lorsqu'on appelle un realloc() avec une nouvelle taille inférieure à la taille d'origine, certaines implémentations [1] ne réduisent pas le bloc d'origine. C'est-à-dire qu'une séquence du style :
# realloc() et fragmentation du tas
Posté par neologix . En réponse au journal realloc. Évalué à 5.
Comme expliqué ci-dessus, dans ce cas il n'y aura pas de fuite mémoire, en cas d'OOM ça finit soit avec le OOM killer soit en segfault.
Mais realloc() a une particularité intéressante qui rend facile l'introduction d'une fragmentation du tas : lorsqu'on appelle un realloc() avec une nouvelle taille inférieure à la taille d'origine, certaines implémentations [1] ne réduisent pas le bloc d'origine. C'est-à-dire qu'une séquence du style :
Conduit à une grosse fragmentation du tas. On a eu ce genre de problème dans cPython.
[1] La glibc n'est pas affectée (http://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=ca1d73f875150a17955df9e0aa2dc33e277aacb5;hb=HEAD#l4168), mais la libc de OS-X si par exemple.