Discussion :

[jcloupgarou]

Bonjour m'sieurs, dames,

ben voila, j'ai un tableau de pointeurs sur une classe CTransformation :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

  vector< CTransformation*> tableau_;

Cet objet fait partie des attributs d'une autre classe CComposant. Je suis dans le cadre d'une simulation longue. Je teste regulierement la taille des tableaux de mes CComposant en appelant la propriété NbTransf() :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
int CComposant::NbTransf()
{
	return (int)tableau_.size();
}

Hé bien, ou bout d'un certain temps, en debug j'obtiens une exception de stack overflow, et en release l'appli se ferme brutalement sans sommation, ou autre message d'erreur... Le CComposant en question est bien défini. Je travaille sous visual et je peux voir la valeur de mon "tableau_" qui est bien vide "tableau|[0]()". Et pourtant ca plante à ce moment là. Ce n'est pourtant pas une partie multi-threadée, donc pas d'accés concurrent...

Plantage à l'appel d'un "size" sur un std::vector, je n'ai jamais vu ca !
Avez vous des idées svp ? Merci !

[Mat.M]

Salut on n'a pas assez de code , comment est alloué CTransformation *, comment il est supprimé donc on ne peut pas trop répondre..

[jcloupgarou]

Le "tableau_" en question sur lequel l'appli plante n'est jamais rempli.
Il est vider dans le constructeur du CComposant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

tableau_.clear();

de base, et plus aucun remplissage aprés !
Il y a justement seulement des accés pour vérifier sa taille et appliquer le traitement adéquate si celle ci est non nulle. Dans le cas de celui qui plante, il est toujours vide et de nombreux accés à tableau_.size() se passent bien, jusqu'au moment ou cela plante !

[mala92]

Dans le cas de celui qui plante, il est toujours vide et de nombreux accés à tableau_.size() se passent bien, jusqu'au moment ou cela plante !

Tu dois avoir un écrasement mémoire quelque part.
As-tu moyen de debugger ? :voir si le vecteur ne se fait pas écraser, par ex, par la variable membre déclarée juste avant lui.

[jcloupgarou]

Oui je traite le probleme en mode debug avec visual studio et je peux espionner la valeur des différentes variables et objets instanciés au moment du plantage.
Le CComposant est bien défini : il comprend beaucoup d'attributs, vector sur des pointeurs, double, int, CString et autres pointeurs sur des classe maison.
Dans l'ordre de declaration, c'est une serie de doubles et de int qui precede le tableau, et ils ont des valeurs tout à fait juste (dans l'espion du débuggueur) et c'est aussi le cas pour tous les attibuts du CComposant.

[dragonjoker59]

Es-tu dans un traitement récursif ou dans une boucle ?

[jcloupgarou]

Tout à fait, c'est un traitement récursif sur un arbre de CComposant ( un attribut de CComposant est un vector<CComposant*>, l'algo se balade de pere en fils et de fils en fils) et à chaque tour de boucle, le code regarde si le "tableau_" du CComposant courant est vide ou pas.

[dragonjoker59]

Ta Stack Overflow vient donc certainement de là.
Vérifie bien ta condition d'arrêt, tu dois être dans une boucle sans fin.

[jcloupgarou]

Bien vu !!!
Effectivement, je fais un code de simulation en physique des particules, traitant les interactions particules/matière et c'était un cas d'un photon avec une certaine énergie qui a l'air de perturber les modèles physiques implémentés : Celui ci ne meurt jamais et le tracking de la particule s'en trouve donc infini.
C'est vachement étonnant, pour un non connaisseur j'entends, que le plantage surgisse toujours au meme endroit dans le code, loin de la recursion sur le tir de particule. Parce qu'en fait, cela n'a rien a voir avec le fameux CComposant ou CTransformation que j'ai décrit précédement !
Je le saurais pour la prochaine fois : stack overflow bizarre = potientiellement un probleme de pile des appels infinie !

[dragonjoker59]

Stack Overflow = Dépassement de pile (généralement d'appels)