Re: [HS] comportement curieux de malloc
Le samedi 29 septembre 2012 à 15:57:49, François Boisson a écrit
:
> Le Sat, 29 Sep 2012 15:22:34 +0200
>
> Erwan David <erwan@rail.eu.org> a écrit:
> > les résultats successifs de malloc n'ont aucune raison
> > d'être contigus. Pour agrandir une zone on le fait plutôt
> > avec realloc, mais ça peut aussi déplacer complètement la
> > zone.
>
> J'étais en train de me pencher sur ça et me doutais d'un truc
> de ce genre... Le déplacement via realloc semble transparent
> (pas clair sur la doc), mais le problème est que visiblement
> ça fait une extension «par le haut» ce qui est ennuyeux,
> visiblement dans le source de camllight, «heap_start» est
> une constante à ne pas toucher. Il y a une fonction
> étendant la mémoire à «sommet constant»?
À mon avis, c’est un gros bogue de camllight de se reposer sur
un comportement non spécifié et dépendant d’une mise en œuvre
particulière.
1. malloc n’a, comme l’a dit Erwan, aucune raison d’allouer des
blocs côte à côte ;
2. realloc n’a pas d’intérêt à réallouer au même endroit, d’une
part parce que, justement, l’intérêt de realloc est de
déplacer l’ancien bloc de façon transparente, et, d’autre
part, parce que ça me ferait bien chier qu’un programme plante
par manque de mémoire parce que la première allocation a été
trop petite et placée dans un petit trou non extensible (ou
qu’une « meilleure » place ne se soit libérée qu’après) ;
3. une fonction intermédiaire « à sommet constant » ne ferait
qu’encourager les programmeurs à faire ce que semble faire
camllight. Quand on se fait un tas, les objets que l’on met
dedans doivent être placés _relativement_ au début du tas, en
clair, on les place par des offset relatifs à heap_start,
laquelle valeur doit être dans une _variable_ qui est utilisée
_à chaque fois_ pour retrouver l’adresse complète de l’objet.
(Et ça fonctionne que ce soit heap_start ou head_end et que
l’on y place les objets en « montant » les offsets ou en les
« descendant ».)
> Merci de la réponse en tout cas.
>
> François Boisson
> PS: Désolé du doublon, je ne comprends pas ce qui c'est pasé
> d'autant plus que les deux messages (identoiques) ont été
> envoyés à 14s d'écart, sous sylpheed, cela signifie aller le
> rechercher pour le réenvoyer aussi sec ce que je n'ai pas
> fait...
Euh, d’après les en-têtes date, il y a 30 min et 8 s entre les
deux… (c. 30 min → délai d’un spool ?)
--
Sylvain Sauvage
Reply to: