[HS] comportement curieux de malloc

Le
François Boisson
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 %d",size);
p=xmalloc(size);
printf("<-0x%16x ",p);
xfree(p);
p=xmalloc(size);
printf("<<-0x%16x",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

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20120929151121.2f2faabe705231f3f3f35669@maison.homelinux.net
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Erwan David
Le #24823972
On 29/09/12 15:11, François Boisson wrote:
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.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
François Boisson
Le #24824052
Le Sat, 29 Sep 2012 15:22:34 +0200
Erwan David
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...

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Bzzz
Le #24824162
On Sat, 29 Sep 2012 15:57:49 +0200
François Boisson
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).

--
Julien : C'est bien pratique le métro quand même
thomas75 : grave
thomas75 : mai il devré fair un métro entre lé ville, et pa sou terre
Julien : Ca existe
Julien : Ca s'appelle un train

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
François Boisson
Le #24824222
Le Sat, 29 Sep 2012 17:01:30 +0200
Bzzz
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).





Ce n'est pas mon code, c'est le code de camllight que j'essaye de débugguer.
Il y a un «heap» plaquée sur l'allocation usuelle (mais non obligatoire de
malloc: Une adresse de fin de zone fixe (heap_start) et une adresse de début
de zone variable (notons la heap_end), on a donc head_end < heap_start. Lors
d'un besoin, un malloc(taille_demandée) est fait et renvoit *généralement* et
pas obligatoirement comme l'a souligné Erwan un pointeur valant head_end -
taille_demandée. C'est vrai que ça marche souvent, ça marche de façon bizarre
si je fais une suite malloc-free-malloc au 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.

François Boisson

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Sylvain L. Sauvage
Le #24824212
Le samedi 29 septembre 2012 à 15:57:49, François Boisson a é crit
:
Le Sat, 29 Sep 2012 15:22:34 +0200

Erwan David > 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 s ur
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éalloue r 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 plan te
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 e n 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 en tre les
deux… (c. 30 min → délai d’un spool ?)

--
Sylvain Sauvage

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Bzzz
Le #24824202
On Sat, 29 Sep 2012 17:47:24 +0200
François Boisson
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.



Il-y-a aussi une autre possibilité, pas vraiment ergonomique ni
rationnelle mais peut-être à même de fixer le PB, ça se rait de
définir une pile fixe [pas sur la tête!;]

--
<molotov> Argh je m'ennuie !!
<Yuk> T'as qu'à te faire un coktail ...

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
François Boisson
Le #24824272
Le Sat, 29 Sep 2012 17:51:46 +0200
"Sylvain L. Sauvage"
À 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 ».)



Ben oui, mais ça ne fait pas mon affaire tout ça, en gros il faudrait que je
refasse la gestion complète de la mémoire de camllight...

Indépendamment de tout ça, c'est tout de même étonnant que la suite
malloc-free-malloc au lieu de malloc suffise à régler (ponctuellement et sur
la version en cours de la libc) ce souci...

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



Ah, c'est déjà mieux, Alzheimer est une explication envisageable vus ces pbms
de mémoire

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
François Boisson
Le #24824342
Le Sat, 29 Sep 2012 17:51:46 +0200
"Sylvain L. Sauvage"
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 ».)



Précision: Visiblement, le code semble tout de même faire des choses relatives
aux bornes, j'ai vu des portions de codes bougeant l'ensemble (bizarrement pas
lors d'une extension dynamique semble-t-il). Il ne reste donc qu'à éplucher
le dit code.

François Boisson

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Tanguy Ortolo
Le #24828902
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.

--
,--.
: /` ) Tanguy Ortolo | `-' Debian Developer _

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/k4ced2$d86$
François Boisson
Le #24829092
Le Mon, 1 Oct 2012 15:55:14 +0000 (UTC)
Tanguy Ortolo
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.



Si il est chez moi depuis longtemps. Initalement il n'était pas dans les
dépots debian car on ne pouvait pas distribuer des binaires issus de sources
modifiés. Le problème était que les sources ne compilaient pas.
J'ai donc
1) Passé outre et distribué des paquets fonctionnels
deb http://boisson.homeip.net/debian «distribution» divers
avec «distribution» de woody à wheezy (ce qui ne me rajeunit pas)
et
deb http://boisson.homeip.net/ubuntu «distribution» divers
avec distribution de breezy, puis dapper à precise

le tout en i386 puis très rapidement i386+amd64.

Ainsi le dernier paquet intègre les petites modifications faites dans le
débugueur et surtout le correctif permettant de profiter pleinement de la
mémoire sous 64 bits (même si ce correctif est une sous sous rustine)

2) Débuggué et transporté le code pour qu'il puisse compiler
sous les libc récentes

3) Fais un paquet source (particulièrement crade mais bon, ça marche)

4) Demandé aux développeurs (INRIA) de modifier la licence (c'est fait depuis
la version 0.81)

5) Obtenu un accès cvs en R/W sur les sources Caml.


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



Ben oui, mais OCaml est obèse.


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

Ça c'est une bonne raison en revanche.




Ben oui.

François Boisson

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Publicité
Poster une réponse
Anonyme