Probleme avec les conteneurs sur visual c++ 2005 express

Bonjour à tous!
Comme l'indique le message, depuis hier, j'ai un probleme avec les conteneurs (vector, list): dans mon projet j'en utilise quelques uns, la génération se déroule sans aucun problème, mais, lorsque je lance le débogage, le programme s'arrète là dans le fichier vector: _SCL_SECURE_VALIDATE_RANGE(_Pos < size());

return (*(_Myfirst + _Pos));
}
avec ce message : "Exception non gérée à 0x006bcb3e dans TerrainDemo3.exe*: 0xC0000005: Violation d'accès lors de la lecture de l'emplacement 0x0fd51001."
J'ai mis des points d'arrêt sur les lignes de déclaration de mes "vector" et me suis rendu compte que le programme s'arrétait avant d'y arriver; d'où mon incompréhension: si le programme n'a même pas encore reçu les conteneurs demandés pourquoi s'arrète-t-il?
En vous remerciant pour votre aide, je vous souhaite de joyeuses fêtes.

L'erreur vient du fait que tu essaies d'accéder à un élément à l'extérieur de ton tableau.

Je viens de revoir mon code à la lumière de ce que vous venez de dire mais je ne trouve pas mon erreur. Lorsque l'on ajoute un élément dans un vector avec push_back peut-on tomber dans le travers dont vous avez parlé ?

Non, mais débuggue pour savoir exactement quand ça arrive et regarde la taille et l'élément accédé.

Merci pour l'aide, j'ai identifié le bout de code à l'origine de l'interruption, c'est celui-ci:
DWORD* adj = new DWORD[g.Wmesh->GetNumFaces()*3];
HR(g.Wmesh->GenerateAdjacency(EPSILON, adj));
(la deuxième ligne).Mais, le problème reste pour moi toujours aussi sibyllin étant donné que "GenerateAdjacency" est une fonction livrée avec le sdk, que je ne peux accéder au corps de la fonction, que j'utilise (au nom des variables près) le même bout de code, sans qu'il ne bug, ailleurs dans le projet, et que j'utilise la fonction correctement (d'après la documentation).
Donc je ne sais pas...
Merci Encore pour l'aide.

L'objectif est de rechercher ce fameux vector dans la pile des appels pour voir d'où cela vient exactement. Pour le moment, on ne peut malheureusement pas t'en dire plus.

En utilisant la pile des appels, la ligne sur laquelle pointe la flèche verte est correspondant à:
TerrainDemo3.exe!std::vector<unsigned long,std::allocator<unsigned long> >::operator[](unsigned int _Pos=1759648) Ligne 760 + 0x8 octets C++
Mais je ne comprends toujours pas (en fait je n'ai jamais lu une pile d'appels), il n'y a pas de référence à un de mes "vector"...
Sinon l'instruction suivante correspond à l'appel
d3dx9d_32.dll!006acb3e()... Merci encore une fois.

Et qui appelle cet opérateur ?

S'il vous plait, Auriez-vous un tutoriel pour apprendre à lire la pile d'appels ? (c'est quelque chose que je n'ai jamais fait et dans mes livres d'apprentissage il n'y en pas).
Sinon, est-ce qu'il faut suivre le code machine qui apparait et repérer les mots clés "call" apparaissant ?

Normalement sur la pile d'appels du debugger de Visual, les appelants sont en bas et les appelés en haut.
Et tu peux double-cliquer sur une ligne représentant une fonction à toi pour aller au code source correspondant.

Merci pour la réponse. Sur la ligne juste en-dessous de celle sur laquelle le programme s'arrête,il y a:
d3dx9d_32.dll!006b1775()

Alors essaie de "remonter" encore plus, jusqu'à atteindre du code à toi.

Alors juste en-dessous, il y a:
TerrainDemo3.exe!CLWater::CLWater(CLWater::InitInfo & initInfo={...}) Ligne 108 + 0x25 octets C++

et lorsque je double-clique dessus, je suis renvoyé à :
HR(g.Wmesh->GenerateAdjacency(EPSILON, adj));

Ce doit donc être cette fonction qui plante: Visiblement, cette fonction utilise un vector, et fait un mauvais accès. Donc, un des paramètres de la fonction doit être mauvais...

Merci. Et maintenant il ne me reste plus qu'à regarder en détail le code.

C'est de toute manière la conclusion à laquelle il fallait s'attendre, le code de DirectX est en général exempté de ce genre de bug ;)

Je te conseille de séparer en 2 ta ligne de code pour voir d'où vient l'erreur exactement.

Séparer quoi?
Le bug se manifeste quand même dans la fonction de DirectX, même si c'est dans l'initialisation de ses paramètres qu'il se trouve...

Code:

---

HR(g.Wmesh->GenerateAdjacency(EPSILON, adj));

---

Pour moi, il y a deux fonctions et pour le moment aucun moyen de savoir quelle est la fonction responsable.

Je ne pense pas. À tous les coups, HR est une macro disant tout simplement "On verifie le HRESULT retourné par la fonction et on... fait un truc... si ça a foiré".

Au passage, auron1, tu auras peut-être plus d'infos en activant la case à cocher dans les options:
Tools -> Options -> Debugging -> Native -> Load DLL Exports.

Tu peux aussi activer le mode debug de directX, MenuDemarrer->DirectX SDK->DirectX Utilities->DirectX Control Panel et cocher le mode Debug (ainsi que les autres options si tu veux). Si ce programme n'est pas dans ton menu démarrer, il est sous "C:\Program Files\Microsoft DirectX SDK (August 2007)\Utilities\Bin\x86\dxcpl.exe"

Voir aussi la FAQ DirectX sur le mode debug.

Salut, Bonne Année 2008 à tous, et merci pour vos réponses. J'ai trouvé le problème : en fait, si la fonction cause un arrêt, c'est parce que g.Wmesh n'est pas crée à cause d'une corruption du tas ("Heap corruption") mais je ne sais pas à quoi cela est dû. Je mets ici un pseudo code de la partie à problème:
for(int n = 0; n < une_certaine_valeur; ++n)
{
for(int a = 0; a < une_autre_valeur; ++a)
{
buildSubMesh(); //une de mes fonctions
}
}
void buildSubMesh()
{
ID3DXMesh** Temp = new ID3DXMesh*; //ID3DXMesh* est le type de gWmesh
...
HR(D3DXCreateMesh(....,....,......Temp));
....
...
...
SubGrid g; //SubGrid une structure contenant un ID3DXMesh*
g.Wmesh = (*Temp);
mSubGrids.push_back(g); // mSubGrids le fameux vector de SubGrid qui n'était pour rien
delete Temp;
}
Voilà; pour a=0 et a=1 tout se déroule correctement la macro HR(x) voit des S_OK mais, pour a=3, "ID3DXMesh** Temp = new ID3DXMesh*;" est exécuté correctement et dès la validation de CreateMesh, dans la fenêtre de sortie, il est écrit "Heap corruption" et HR(x) voit un E_OUTOFMEMORY(mais l'execution ne sera arrêtée que plus tard).
Même en activant le mode debug je n'est pas plus de précision sur mon code, à part que l'exécution s'arrête aussitôt le problème rencontré et m'envoie sur
cette partie du code du fichier(fourni avec le sdk ou visual c++) xutility :
template<class _InIt> inline
void __CLRCALL_OR_CDECL _Debug_range(_InIt _First, _InIt _Last, const wchar_t *_File, unsigned int _Line)
{ // test iterator pair for valid range
là-> _Debug_range2(_First, _Last, _File, _Line, _Iter_cat(_First));
}

Normalement, si j'alloue de la memoire dans le tas dans une fonction à l'aide de new, utiliser delete libère cet espace et le fait que ce soit local n'est-il pas censé garantir qu'à chaque appel de "buildSubMesh()" "Temp" n'ait rien à voir avec les précedents ?
:cry:Je ne comprend vraiment plus rien.

Salut et très bonne année à toi aussi !

En attendant une réponse pplus sure, voici déjà quelque chose qui me choque :

Citation:

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

void buildSubMesh() { ID3DXMesh** Temp = new ID3DXMesh*; //ID3DXMesh* est le type de gWmesh ... HR(D3DXCreateMesh(....,....,......Temp)); .... ... ... SubGrid g; //SubGrid une structure contenant un ID3DXMesh* g.Wmesh = (*Temp); mSubGrids.push_back(g); // mSubGrids le fameux vector de SubGrid qui n'était pour rien delete Temp; }

---

---

Je parierai que l'erreur est ici.

Tu dis "SubGrid est une structure contenant un ID3DXMesh*". Or en C++ structure == classe. Le souci est que cette classe contient un pointeur. L'objet g est crée dans la fonction et sera détruit dans la fonction. ll utilise le constructeur de copie. Si tu n'en as pas spécifié, il va simplement faire une copie rigoureuse membre à membre de Temp.

Donc le(s) pointeur(s) que contient g pointeront sur la meme zone de mémoire que Temp. Ensuite le pushback fait une copie de g. Donc dans le vecteur, l'élément que tu ajoutes pointe toujours vers la zone de Temp.

Or Temp est crée dynamiquement et tu le détruis après le pushback. Donc la zone pointée par l'élément dans le tableau devrait être invalide non?

Merci pour l'indication, j'ai modifié cette partie du code, elle se présent maintenant comme ceci:
mSubGrids.resize(nbre_par_col*nbre_par_ligne); // toujours mon vector de structure SubGrid
int p = 0;
for(int n = 0; n < nbre_par_col; ++n)
{
for(int a = 0; a< nbre_par_ligne; ++a)
{
buildSubMesh(mSubGrids[p].Wmesh);//Wmesh est toujours un ID3DXMesh*
p += 1;
}
}

void buildSubMesh(ID3DXMesh* pMesh)
{
pMesh = 0;
...
HR(D3DXCreateMesh(...., ....,.....&pMesh));
....
....
}
Mais, j'ai toujours le même problème de corruption du tas et E_OUTOFMEMORY par HR(x).