jai proge un generateur  demonde ...
le truc est recursif font et ca fonctionne le hic c'est quand je veux generer des mondes trop grands au dela de 900x900
ca pete des segfault (normal vut ke c'est du recursif)
 
donc je cherche un moyen de verifier letat de la pile en temps reel  
de maniere a en liberer quand c'est a la limite du segfault .... et ainsi pouvoir generre des mondes encore plus grands ))  
 
truc rigolo : ce prog sous window limitais les mond a 200x200 apres cette limite segfault je compile le meme code sous linux et la je peux generrer du 900x900 ))))) aprs segfault

programmes le en Caml,
 
ou alors verifies que tu ne peux pas derecursifier
ton programme (c'est souvent le cas)!
Evites d'allouer un trop grand nombre de variables
sur la pile, si une variable
n'est valide qu'entre deux appels a la fonction  
recursive deplace la en global.
 
A+
LEGREG

 
a part econnomiser de la pile ...  
on ne peux pas savoir ou on en est dedans ??? de maniere a depiler au dernier moment ? ...
 
 
 
comment savoir a quel adresse le pile commence en memoire ???
et ou est la tete de pile en memoire ??
 
car si je sait cela je peux en deduire le taille qui me reste a coup de sbrk();
sachant que l'espace mem qui me reste vaudrat  
(tete de pile) - sbrk();
et quand ca est trop pres de 0 je depile et basta

sbrk? ca n'existe que sous Unix (Linux), non ?
 
pour connaitre la taille prise par la pile
c'est simple: tu peux le prevoir en connaissant
par avance la profondeur des appels recursif que tu fais
(d'ou l'importance de savoir ce que tu alloues sur la pile!)
 
de plus, le bas de la pile c'est lorsque tu es au niveau
zero de tes appels recursifs, pas tres complique a concevoir.
 
A+
LEGREG

 
 
sbrk est une fonction linux qui te permet de savoir a quel adresse est le haut de ta pille de malloc (cette pile de malloc vas a l'encontre de la pile en memoire) ccl lespace entre le haut de la pille et ladresse que te renvoie sbrk est de la place libre pour soit des mallocs soit du mangage de pile
 
la pile elle se trouve juste avant le kernel  
 
en gros
vla ta memoire sous linux
[[zone de texte][zone de data][malloc->>>> .               <<<-pile][kernel]]
                   sbrk() me donne cette adresse |
 
si je sait ou demmare ma pile je serait a moitie sauvé koike la pile est aussi limite
mais bon ta la raison la pourquoi quand tu malloc tu perd de la pile .........

je connais sbrk, je te faisais juste remarquer
que ca ne marchera que quand tu es sous Linux..
 
Pour l'endroit ou demarre la pile, tu as la reponse dans mon post precedent a quelques chouai d'octets pres.
 

 
Mouai, ca ne tient pas a moins que tu comptes
utiliser plus de 4 Go de memoire conjuguee pile + tas
et tu auras plus probablement deja fait plante ta machine
bcoz manque de memoire physique + swap..
 
A noter que sous certains systemes (Solaris + threads)
la pile a une limite intrinseque mais ca ne change rien a ton probleme.
 
Tu ne penses pas que ce serait plus simple de revoir ton algo et la facon dont tu alloues tes objets :??
 
LEGREG

Il y a un truc que je ne comprends pas, là.
Si la pile n'a pas de limite intrinsèque, et qu'il n'alloue pas 4 Go avec malloc de façon à rejoindre la pile dans l'espace d'allocation, comment se fait-il qu'il soit impossible d'empiler autant d'appels récursifs qu'on veut ?

a mon avis, le probleme c'est le code
 
LEGREG

Oui, ça me paraît plus plausible...

 
sur du linux la pile ne vaut ke 32Mo envrion
vais revoir mon code je pourrais gagner quel que cases suplemaentaires ... mais ne ferrais que repousser le problemen un peut plus loin
sinon jessayerrais de faire ca en iteratif ....  

Je me trompe peut etre, mais est ce que la taille de la pile n'est pas modifiable avec ulimit?

Gagné.

 
    vais essayer je vious tiens au courant