Push_back() de std::vector

Version imprimable

02/05/2009, 15h55
tir0nik

Push_back() de std::vector
Bonjour,

Comme le titre le laisse présumer j'ai un problème avec la methode push_back des vector.

J'utilise donc les vector dans un programme et à un moment donné (toujours au bout du troisième appele à push_back), J'ai tout qui bug.

J'ai essayé de récupérer une exception mais ne maîtrisant pas vraiment le sujet je ne sais pas si j'ai fais correctement. Quoi qu'il en soit ça bug et ça n'affiche rien.
Code:

1 2 3 4 5 6 7 8 9 10 11 block tmpBlock; tmpBlock.name = blockname; try { listBlocks.push_back(tmpBlock); } catch (const std::exception& ex) { std::cerr<<"Error : "<<ex.what()<<std::endl; }
Je pense que c'est dû au fait que la structure "block" que j'ajoute contient elle-même un vector mais alors je ne vois pas comment résoudre le problème...
Code:

1 2 3 4 5 struct block { std::string name; std::vector<option> listOptions; };
Comment faire pour résoudre mon problème ?

à noter que ce bug se produit uniquement sous vista (mais ça marche quand meme une fois sur cinq), il n'y a pas de problème sous xp.

Merci
02/05/2009, 18h41
ram-0000

Question bête, est ce que ta structure "block " possède un opérateur de copie valide (ou bien est ce que l'opérateur de copie par défaut est suffisant) et pareil pour ta structure ou classe "option" ?
02/05/2009, 20h02
mazipha

Est ce qu'il n'y a pas tout simplement une fuite mémoire ailleurs qui vient corrompre ton vector? Ca m'est déjà arrivé et c'est assez vicieux à debugger car l'erreur n'est pas là où on croit. Ou alors une corruption multithread (manque de mutex de protection)

Qu'est ce qui te faire dire que c'est au 3 ème push_back que ça plante? Tu as mis des traces?

As tu essayé d'isoler le problème sur un petit programme de quelques lignes?
Si oui, poste le code complet de ce petit exemple.

Voici en (très) gros ce que fait mon programme :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 #include <iostream> #include <vector> struct attribut { std::string name,value; }; struct option { std::string name; std::vector<attribut> listAttributs; }; struct block { std::string name; std::vector<option> listOptions; }; int main() { std::vector<block> listBlock; for (unsigned int i = 0;i<100;i++) { block b; b.name = "block"; listBlock.push_back(b); std::cout<<"block "<<i<<" created"<<std::endl; } system("pause"); return 0; }
Sur cet exemple ça ne bug pas, pourtant mon programme suit exactement ce principe.

Citation:

Envoyé par ram-0000

Question bête, est ce que ta structure "block " possède un opérateur de copie valide (ou bien est ce que l'opérateur de copie par défaut est suffisant) et pareil pour ta structure ou classe "option" ?

Je pense que les opérateurs de copie par défaut sont suffisants.

Citation:

Envoyé par mazipha

Est ce qu'il n'y a pas tout simplement une fuite mémoire ailleurs qui vient corrompre ton vector? Ca m'est déjà arrivé et c'est assez vicieux à debugger car l'erreur n'est pas là où on croit. Ou alors une corruption multithread (manque de mutex de protection)

Qu'est ce qui te faire dire que c'est au 3 ème push_back que ça plante? Tu as mis des traces?

As tu essayé d'isoler le problème sur un petit programme de quelques lignes?
Si oui, poste le code complet de ce petit exemple.

Je ne voit pas comment il pourrait y avoir une fuite de mémoire je n'utilise pas d'allocation dynamique. Mais peut être qu'il n'y a pas assez de mémoire disponible ? (dans ce cas push_back() devrait lancer un bad_alloc non ?)
Et non je n'utilise pas de thread ici.

Pour savoir que c'était au 3ème push_back, j'ai tout simplement "mis" des cout avant et après chaque push_back, Et j'ai vu qu'il plantait au 5ème (cout).

EDIT :

Bon j'ai finalement installé code::block sous vista et quand je compile (même le code minimal qu'il y a en haut) il me sort des :

Code:

C:\Program Files\CodeBlocks\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\include\c++\3.4.5\bits\stl_uninitialized.h|82|warning: '__cur' might be used uninitialized in this function|

Voici la liste complète de warning pour le code d'en haut :

Citation:

||=== testvector, Release ===|
stl_uninitialized.h|82|warning: '__cur' might be used uninitialized in this function|
stl_uninitialized.h|82|warning: '__cur' might be used uninitialized in this function|
stl_vector.h||In member function `std::vector<_Tp, _Alloc>& std::vector<_Tp, _Alloc>::operator=(const std::vector<_Tp, _Alloc>&) [with _Tp = attribut, _Alloc = std::allocator<attribut>]':|
stl_vector.h|715|warning: '__result' might be used uninitialized in this function|
stl_uninitialized.h|82|warning: '__cur' might be used uninitialized in this function|
stl_uninitialized.h|82|warning: '__cur' might be used uninitialized in this function|
stl_vector.h||In member function `std::vector<_Tp, _Alloc>& std::vector<_Tp, _Alloc>::operator=(const std::vector<_Tp, _Alloc>&) [with _Tp = option, _Alloc = std::allocator<option>]':|
stl_vector.h|715|warning: '__result' might be used uninitialized in this function|
stl_uninitialized.h|82|warning: '__cur' might be used uninitialized in this function|
stl_uninitialized.h|82|warning: '__cur' might be used uninitialized in this function|
stl_uninitialized.h|82|warning: '__cur' might be used uninitialized in this function|
stl_uninitialized.h|82|warning: '__cur' might be used uninitialized in this function|
||=== Build finished: 0 errors, 10 warnings ===|

Qu'est-ce qu'il se passe ?

Merci pour vos réponses :D

03/05/2009, 14h33
jfouche

Pour les warnings, a confirmer, mais il me semble que cela vient de la STL fournie avec gcc 3.4.5. Tu peux les ignorer.
Pour l'erreur, la vérité est ailleurs...
--
Jérémie
03/05/2009, 16h37
tir0nik

Aussi j'ai essayé le debugger sous vista et là... Aucun bug 8O niet, rien qui plante, par contre dès que je lance en "normal" tout plante.
03/05/2009, 16h51
Arzar

Citation:

Envoyé par tir0nik

J'ai tout qui bug.
...
Pour savoir que c'était au 3ème push_back, j'ai tout simplement "mis" des cout avant et après chaque push_back, Et j'ai vu qu'il plantait au 5ème (cout).
...
Aucun bug niet, rien qui plante, par contre dès que je lance en "normal" tout plante.

Il se passe quoi exactement à part "tout qui bug"? Qu'est-ce que les traces sortent ? Ce n'est pas très clair.

Edit : Par exemple, quand tu lances le programme au debuggeur, est-ce qu'il y a une différence de comportement entre le mode debug et le mode release ?
03/05/2009, 17h37
tir0nik

Quand je dis tou qui bug c'est : machin.exe a cessé de fonctionner Windows recherche une solution...

Sinon quand je lance le programme au debugger, non il n'y a strictement aucune différence entre le mode release et debug, ça marche.
03/05/2009, 19h00
Matthieu Brucher

Ca ressemble beaucoup à une corruption mémoire, ton truc. Simplifie ton programme au maximum, sans quoi tu seras INCAPABLE de trouver d'où vient l'erreur.
Il faudrait que tu passes par un débuggeur plus avancé pour trouver l'erreur (genre TotalView), mais bon, c'est en général payant.
03/05/2009, 19h21
tir0nik

Citation:

Envoyé par Matthieu Brucher

Ca ressemble beaucoup à une corruption mémoire, ton truc. Simplifie ton programme au maximum, sans quoi tu seras INCAPABLE de trouver d'où vient l'erreur.
Il faudrait que tu passes par un débuggeur plus avancé pour trouver l'erreur (genre TotalView), mais bon, c'est en général payant.

Merci beaucoup !!! ça marche !

J'ai fait comme t'as dit, j'ai simplifié au max,j'ai supprimmé des fonctions au fur et à mesure et à un moment donné ça n'a plus buggé.
En fait c'était un dans une fonction rien à voir mais appelé pas mal de fois.

Code:

char* tstr = new char[size+1];

(oui il y à une raison à ce que j'utilise un char*)
J'avais oublié le "+1" et du coup ça fonctionne.

En outre j'avais aussi mis quelques "delete" à la place de "delete[]" mais ça n'avait pas l'air de changer grand-chose.

(Maintenant à savoir pourquoi ça marchait sous xp et pas sous vista c'est autre chose).

PS: j'ai rien dit quand je disait que j'utilisait pas l'allocation dynamique, en fait elle est omniprésente dans cette fonction mais je ne pensait pas que cette fonction avait quelque chose à voir.

Merci à tous :D
03/05/2009, 19h26
Matthieu Brucher

Il suffit que XP alloue légèrement plus, ou à un autre endroit, avec un autre alignement, et plus de bug.
Il me semble qu'avec /Gs tu peux ajouter des gardes à tes blocs de données sous Visual Studio (à confirmer).