[HS] comportement curieux de malloc

Bonjour,

J'ai bien conscience du HS de ce message masi il y a sur cette liste des
programmeurs avertis.
Je maintiens le paquet de camllight et le debug au fur et à mesure (il n'était
pas libre lors de la version 0.74). Il est utilisé en CPGE donc il faut le
maintenir à flot (par ailleurs il est 100x plus léger que ocaml).
Il y a un bug curieux dans la version 64 bits:

camllight utilise une pile dynamiquement étendue vers le bas via des mallocs
judicieux. Or dans la version 64 bits, cette pile est soudainement saturée
très rapidement (trop). Qui plus est un free propre de la dernière allocation
plante le système. En fouillant, je me suis aperçu que la première allocation
n'est pas contigue des suivantes. Pour être exact voilà ce que donne la
succession d'appels de la fonction

char *xmallocverbeux(asize_t size) {
char *p;
printf("->demande de %dn",size);
p=xmalloc(size);
printf("<-0x%16x ",p);
xfree(p);
p=xmalloc(size);
printf("<<-0x%16xn",p);
return(p);
}
(xmalloc étant malloc):

<-0x 5a768010 <<-0x 1bb3820
<-0x 1c17a40 <<-0x 1c17a40
<-0x 1c58aa0 <<-0x 1c58aa0
<-0x 1d50af0 <<-0x 1d50af0
<-0x 1d91b10 <<-0x 1d91b10
<-0x 1dd2b30 <<-0x 1dd2b30

La première ligne est celle qui met le bazar, en effet sans l'appel
malloc-free-malloc (illogique) la première allocation définissnant le sommet de
la pile puis les autres étant des augmentations successives, la pile ne peut
être étendu et bing «Out of memory» (ce qui énerve assez avec 4G de RAM)

La rustine est évidente mais je ne comprends pas ce comportement singulier au
malloc sur architecture 64 bits. Si quelqu'un a une explication/
(cela faisait plusieurs mois que je butais sur ce bug).

Merci

François Boisson

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.

clair sur la doc), mais le problème est que visiblement ça fait
une extension «par le haut» ce qui est ennuyeux, visiblement da ns
le source de camllight, «heap_start» est une constante à n e pas
toucher. Il y a une fonction étendant la mémoire à « sommet
constant»?

Qu'est-ce que tu entends par "par le haut", une pile est une pile;
après suivant qu'elle soit LIFO ou FIFO c'est la logique du niveau
juste au-dessus de ton morceau de code qui détermine ça - et que les
adresses de ses éléments soient croissantes ou décroissantes ou
aléatoires n'a que peu d'incidence (sauf en cas de débordement du
segment).

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»?

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...

lieu de malloc, mais c'est clair que c'est non satisfaisant. Il y
a donc comme solutions
* réecrire tout le bazar: avec ocaml, c'est peut être idiot
* se contenter de ma rustine... bof.
* essayer de voir si il y a moyen d'assurer un mécanisme faisant
grossir le «heap» tel que voulu.

À 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.


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 ».)

> 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 ?)

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 ».)

J'ai bien conscience du HS de ce message masi il y a sur cette liste des
programmeurs avertis.
Je maintiens le paquet de camllight

Il est utilisé en CPGE donc il faut le
maintenir à flot

(par ailleurs il est 100x plus léger que ocaml).

François Boisson, 2012-09-29 15:11+0200:
> J'ai bien conscience du HS de ce message masi il y a sur cette liste des
> programmeurs avertis.
> Je maintiens le paquet de camllight

Quel paquet de camllight ? Je ne vois rien de tel dans Debian,
malheureusement.

> Il est utilisé en CPGE donc il faut le
> maintenir à flot

Bof, ce qui est fait en prépa en Caml Light doit bien tourner avec OCaml
non ?

> (par ailleurs il est 100x plus léger que ocaml).

Ça c'est une bonne raison en revanche.