Le portail francophone de la géomatique

Arf ! C'est un des reproches à faire à gvSIG. Lorsqu'on obtient une erreur, on comprend pas bien le message.... je ne sais pas si c'est une spécificité aux programmes écrits en java !

Désolé je ne peux pas répondre à ta requête, je te suggères de poster un message sur la liste gvsig ici : http://runas.cap.gva.es/mailman/listinf … ernacional ou ici http://n2.nabble.com/gvSIG-f2000051.html
Tu es sur quel OS?

Dernière modification par Sylvain33 (Sun 29 March 2009 00:16)

Salut,

Les messages type "java.lang.StackOverflowError" sont symptomatiques en Java d'un dépassement de la mémoire de pile de la machine virtuelle. Ceci se produit notamment lors de l'appel à des méthodes hautement récursives (parsing XML, transformation XSLT, etc.). La solution, s'il est impossible de modifier la méthode à l'origine de l'erreur (et dans bien des cas, c'est le cas ;-) ), est d'augmenter cette mémoire de pile. Par défaut, celle-ci varie en 128Ko et 512Ko suivant les versions de Java et du système d'exploitation. Pour l'augmenter, il existe un paramètre -Xss à passer à l'interpréteur Java.

Un java -X sur une invite de commande ou un shell Linux te donnera l'ensemble des options qui permettent de jouer avec les seuils de mémoire de la machine virtuelle Java. Si tu lances un programme Toto et que tu veux augmenter la mémoire de pile disponible pour celui-ci, le lancer par la commande :

java -Xss1m Toto

Ceci fera passer la mémoire de pile disponible à 1 Mo

Pour GvSIG, tu dois avoir un appel à l'interpréteur Java dans un des scripts de démarrage du logiciel (je n'ai malheureusement pas les scripts sous les yeux) car celui-ci repose sur ce langage. Une fois que tu l'as isolé, intercale dans l'appel ton paramètre -Xss avec la valeur voulue et relance GvSIG et ton traitement, si cela ne marche toujours pas, ré-itère l'opération en augmentant encore ta taille de pile insérée.

En espérant que cela aide,

Th.

--
Thierry Badard
Département des sciences géomatiques
Faculté de foresterie et de géomatique

En fait, c'est un brin plus compliqué que cela ... chaque thread créé dans le processus de votre programme se voit "alloué" une mémoire de pile. Naturellement, plus la taille de pile passée est grande, moins un programme pourra créer de threads sous peine de lever un message d'erreur comme quoi la mémoire est saturée. Ceci est particulièrement valable sur les processus serveurs en Java. Ils sont en effet susceptibles de recevoir beaucoup de requêtes utilisateur et donc de créer de nombreux threads afin de traiter celles-ci en "parallèle".  Voilà pourquoi cette taille est volontairement basse par défaut.

Est ce que cette mémoire est prise d'un coup ou allouée dynamiquement au fur et à mesure des besoins du thread ? Bonne question ... Il faut tester et regarder comment évolue la consommation mémoire de votre programme, car il me semble que cela dépend du système d'exploitation ... Sun est assez avare de détails sur ces points là car ils touchent bien entendu aux caractéristiques qui différencient en termes de performances une JVM d'une autre ;-).

En espérant que cela aide,

Th.