bonjour,
 
voila sans perl et sans reproche je tape la main dans mon script
des tonnes de lines pour un prog de test de non regression.
 
test cases test suites  dans tous les sens
 
 
des new partout ( je fais normallement du C pousse-pousse alors j aime bien l'OO qiand je peux)
 
un premier test avec qqs fichiers de test , nikel
 
puis test un peu plus mouse avec 1000 test case repartis a peu pres equitablement en bloc de 20 test suites et..
 
 PAF , the claque.
 
 
<b>out of memory during request un sbrk() is 1017584044 </b>
 
alors la je tape sbrk sous yahoo (mon man a moi) et re claque,  
ca fait trop longtemps que j ai pas eu de cours de compil et je suis pas sur de tout piger.
 
heureusement vous etes la..
alors? une idee

Quelle version de Perl utilise tu?
Esque tu utilise des modules avec du XS?
 
Esque tu fait des choses.... etranges?
 
En gros il fait koi ton bout de code qui plante (si tu a pu l'isoler) ?

perl 5.6.1
 
des choses etranges? ben le prog est assez simple
un objet pour gerer les test suites
un test suite etant composee de sous test suite et de test cases
 
un run sur cet objet provocant un run de ses sous suites et de tous ces cases.
 
un mecanisme de reporting ( et a monn avis c'est la que ca merdouille) dump ensuite les resultat (passed or failed ) en format hacheteumeuleu .
 
je teste en fait le resultat d'une requete sur un serveur en dumpant sous forme xml le resultat ( via un schema genere automaitquement  d apres l idl )
 
..tiens en le disant je me rends compte  que finnalement oui je fais des choses bizarres.
 
sinon ma question pourrait etre ,:
 
y a til qqch a faire lorsque l'on sais que l on doit garder des gros objets en memoire avec perl ?  
un truc du style sbrk(100000000000000) ?
 

Il y a pas mal de solution pour reduire al conso memoire, notament au niveau serialisation
mais tout dépend de tes sturctures, c'est difficile à dire comme ca...
Si tu ne fait pas d'heritage tu peut regarder du coté de... putain je me souviens plus du nom du module est search.cpan est en panne...
 
enfin ya des modules qui permettent une meilleur gestion memoire en OO. deja tu peux regarder du coté du pragma "filds" (je ne sais pas quelle version il y avait dans perl 5.6...)
 
Mais il faudrait que je retrouve le nom de l'autre module, il est terrible si tu a un tres tres grand nombre d'objets à traiter
 
la probleme vient du nombre d'objet ou de la taille de chaque objet à ton avis?
 
tu utilise un prog externe d'ou pourrait venir l'erreur? le serveur lui il est content (question inutile, dont je ne vois pas le sens...) ?

il y a de l heritage, j'herite en fait de clase testcase et test suite existantte . c'est grace a cette heritage que le mecaisme de reporting peut etre utilise ( une methode permet de reporter une failure , et donc ce test,suite ou case, sais kil a plante , bien sur ondit pourquoi dans la methode ..bref je ne me tends pas trop)
 
bon je vais aller voir le mec qui a ecrit les classes de base et le pseudo framework de test.
 
mince moi qui penser me liberer de cette tache de test assez vite
 
 
pour le dilemme taille / nombre , ben c est sur que si un objet occupait moins de place j aurai ptet pas le probleme , mais comme c est incompressible (je veux dire par la que j ai pas d autre choix que d utiliser ce mecanisme , et donc ce type de classe) , dans mon cas c est le nombre qui fait tout deborder.
bon evidement je pourrait tricher et modifier la logique en disant qu'il n y a non plus 1 seul test suite de base mais plusieurs ( et donc provoquer la generation html plus vite)
 
mais ca serait un peu de la bidouille , puisqu il faudrai que je rajoute une couche qui , connaissant tous les tests suite racine, me dise si mon test 'general' (l ancien test suite racine unique) a reussi..  sachant que ca normalement c'est pas a moi de le faire car ce mecanisme est integre au test suite..ben j vous plaint a lire ces details..  
 
 
le serveur lui , comme tu t en doutes , se moque que le client fasse des conneries avec ce qu'il renvoie ( a la mlimite c'est meme pas sur la meme machine..)  
 
<citation> bon pendant ce temps la je suis pas au bistro </citation>  
 
 
bon je vais regarder cette histoire de pragma gedon

bon courage...

merci !
 
ps a taz: je preferer mon titre de subject

et moi je n'éprouve pas le besoin de faire l'intéréssant au point de devoir écrire « subject »    

les bras m'en tombent ..taz ta remarque me sidere (tu peux regarder dans le dico c est francais..).
on parle de pragma , de framework et d'object avec des out of memory et toi tu trouves ca carrement irreel d'employer le mot subject.. ben tu dois en corriger des "topics"  ( =~ sujet )  
 
bon sinon j ai un expert PERL  (Practical Extraction and Reporting Language ...) aussi auteur de l outil de reporting qui va venir me filer un coup de main
 
je vous poste la reponse ( the answer)
 
 
 
 
 

Félicitations, c'est la première fois de ma vie que je vois un sbrk échouer. T'as dû y aller très très fort quand même.
 
arriver à mapper tout la mémoire physique + tout le swap dans un seul process, c'est très fort.
 
C'est quel OS ?

le problème étant que sbrk n'est pas mmap

J'ai pas compris.

bien avec un système comme Linux, prenons le code de malloc. en fonction de la taille demandée, malloc fait soit un appel à mmap (projection de fichier en mémoire) soit un sbrk qui fait grandir le segment. mmap pour les grandes demandes, sbrk sinon. si sbrk échoue, c'est que FrenchKiss doit allouer une fourmillière de petits objets il me semble, et que l'interpréteur Perl est mal foutu de ce côté là peut être. bref, même si ça tourne, ça sens la fragmentation mémoire à plein nez

et il mappe quoi en mémoire avec mmap ? (je savais même pas qu'il utilisait ça)

ben quand tu fais sbrk, la mémoire physique est réclammée directement. quand tu fais avec mmap (utilisable pour projeter n'importe quel fichier), et bien il projete /dev/zero (du vide quoi) et n'alloue les pages qu'à l'utilisation. de plus que les mécanismes qui vont avec mmap sont beaucoup plus subtils. mais un peu plus lent donc réservé au grandes plages (aucun intéret pour quelques octets, il vont forcément être écrit immédiatement)
 
 
bref on dirait que l'allocateur Perl a du mal, est mal foutu, mais j'y connais rien du tout.

Ah ok, merci.
 
Sinon, un allocateur normal double la taille à chaque fois, mais dans le cas de perl, je sais pas.

le mode d'allocation de al memoire de perl est défnini au moment de la compilation de l'interpreteur perl. Je sais que j'avais pleins de galeres de memoire avec activeperl 5.6 (il rendait jamais al memoire, meme apres un undef franc et massif d'une variable), et ca marchait beaucoup mieux avec SiePerl 5.6 (un perl compilé par siemens). Mais toujours est-il qu'abvec avtive perl 5.8 tout est rentré dans l'ordre pour moi: il gere beaucoup mieux la memoire
 
donc frenchkiss, si tu utilise active perl 5.6 sous windows, essai de passer à la version 5.8 pour voir...

bon je suis sur le point de quitter le taf ,
j ai regarder la doc ($ENV{PERL_DEBUG_MSTATS}) sans grand succes pour l instant.
je suis sous unix et malheureusement (ou heureusement diront certain) je n ai pas encore tout pouvoir dans ma boite , donc va falloir que je me debrouille avec cette version de perl.
 
(j ai essayer en exportant cette etrange variable , de chiffres tres bizarres apparaissent )  
et meme documentes j y comprends rien ...
 
bon demain je m'y recolle  
 
merci pour vos reponses , si je trouve qqch je post.
 
FK
 
 

c'est très très courrant ce type de comportement

si qqun connait l'equivlent de purify pour perl
bon j'my recolle (berk)
 
bon vendredi qd meme.

Perl ne corromp pas la mémoire par nature, c'est à un bug de la VM que tu es confronté, pas à un bug à toi. Tu ne peux que rapporter le bug aux auteurs et tenter de le contourner.

bah oui , mais faut bien qu il tourne mon prog, je dois donc connaitre cette limite pour pouvoir faire un work around (special dedicasse pour taz)

check la five point height juste pour voir si ca work with

Juste pour completer mon message sur le module qui permet de gagner de la place si on a un tres grand nombre d'instances:
http://search.cpan.org/~jasons/Cla [...] plate-0.7/
 
C'est un module qui etait decrit dans advanced programming in perl
 
En fait son principe c'est au lieu d'utiliser un hash pour chaque objet, avec les attributs de l'objet dedans, il cré un array pour chaque attribut de ta classe, mais commun à tous les objet: chaque instance a un rang auquel elle va chercher la valeur de chaque attribut dans le array correspondant
 
Donc si tu a 10000 objet et 5 attribut, au lieu d'avoir 10000 hash avec 5 entrée (ou 10000 array de longueur 5 comme avec le pragma fields, et c'est deja mieux que les hash niveau memoire et 15% plus rapide), et bien avec ce module tu aura 5 array de longueur 10000!
 
Il me semble que l'heritage est aussi prevu, mais bon dans ton cas ca te servira à rien de toutes facon vu que tu herite d'une classe qui n'est pas gerée comme ca...
 
Bon de toutes facon ce module est tres rarement utilisé on dirait, et le mieux c'est d'utiliser fields
 
De toutes facon tout ca sera reglé avec Perl 6! La syntaxe objet sera trop belle, un peu à la Ruby!! Enfin va falloir etre patient...
 
bon, desolé pour la digression...

un avant gout de la future syntaxe objet de Perl 6, pour deja l'avoir en Perl 5 (mais avec une implementation à base de filds derriere...).
 
http://search.cpan.org/author/LPAL [...] Classes.pm
 
(à ne pas utiliser pour de vrai, car comme c'est juste un filtre sur le code avant l'interpretation ca peut entrinaer des bugs etranges...)

interressant.
plus propre au niveau de la definition c sur.
 
finallement les langages finissent par beaucoup se ressmbler...
 
 
 
 

un Desin Pattern PoidsMouche/FlyWeight en somme

tu parles du rapport entre le langage et son interpretation je suppose.
 
bon sinon je fais des tests  
c assez bourrin , vu que comme j ai trouver aucun outil , j ai commenté certaines parties du cde ou je faisais des trucs un peu lourd ou des appels a la librairie dont je depends.
et je les recommente jusqu'a ce que je parte en out of memory.
bon c vrai rien ne me di que c est pas la somme de toutes les methodes decommentées qui pose le probleme plutot que la derniere ( je vous entends venir en criant au n importe quoi ).
mais zai pas le choix ( pis comme je l ai dit je fait pas grand chose a part des E/S dans fichier et appel a des methodes de comparaison)
 
je m aide de la variable specifiee dans ce post et qui me donne la memory allocation a la fin de chaque exceution.
ca varie peut quand je decommente certaine partie et ca explose juste si j ajoute un appel a une methode de diff (ecrite par le fameux expert qui m a plante...)
donc je crois avoir trouver la methode coupable.
 
reste a lui ouvrir les entrailles..
 
quel boulot de bourrin , tout ce temps a l ecole pour en arriver la , chui pas sur que c en vallait la peine
 
 

en fait, tu crais des objets et du les efface ensuite? ou tous els objets doivent etre en memoire en meme temps?
 
si c'est el premier cas, peut etre qu'ils ne sont pas correctement detruits: Perl ne detruit un objet que si aucune reference à cet objet n'existe
 
Donc tu a peut etre laissé trainé une reference qq part?
 
essai de mettre une sub DESTROY dans ta classe, elle sera automatiquement appelée si l'objet et detruit, et dans ce cas c'est bon. Mais si elle n'est pas appelé c'est que l'objet n'est pas detruit...
 
donc fait simplement un truc du genre
 
sub DESTROY {
    my $self = shift;
    print $self->{nom} . " detruit\n";
}

hello !!
 
bon alors j ai isoler la methode incriminee et fait un script qu appel cette methode 1000 fois ( comparaison entre 2 fichiers xml)
 
et paf , out of memory !!!
 
voila donc c'est sur c'est bien cette methode qui fou la zone  
(elle consomme eneormement de memoire)
 
 
merci et bonne semaine a tous
 
 
 

Non, dans le cadre du poidsmouche il change de représentation. La complexité totale ne change pas mais il a une représentation plus efficace.

up ! pour en revenir a mon probleme c'est resolu ,  
c'etait bien la methode qui posait probleme.
 
mais vous aller rire..
 
imaginez que vous avez un fichier de 10 739 438 lignes..
a parser ( extraction d'info)
quel solutions mettreriez vous en oeuvre?
par ce qu'a priosi un open  provoque un ..
 
Our of memory during "large " request...
 
(enfin pas le open en lui meme , mais le <FILE> )
 
toujours en perl 5.6.1

Ha c'etait ca?
Ben c'est sur que si tu fais un truc genre
@a = <FILE>
ca va charger la totalité du fichier dans @a, mais si tu fait un:
while(<FILE> ) {...
la ca va le faire ligne par ligne...
 
je suis un peu déçus...

non le probleme inititail etait du a des cycles dans un graphe
d'objet ( representant le fichier XML) , j en sais pas vraiment plus , vu que ce n'est pas moi qui cree ce graphe , j ai recu un patch et plus de soucis.
 
ce probleme etant resolu mon script a tourne et ma genere ce fameux fichier de 10 millions de lignes , et une fonction appellee qvec ce fichier en parametre (avec regexp) etait pas trop prevue pour avaler tant de donnée (undef $/)  , je l ai effectivement modifiee et ca roule.
 
enfin comme tu le dis pospos ce 2eme etait tres facile a identifier ( ffectivement).
 
bon voila tout tourne maintenant !