Discussion :

[tir0nik]

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 :

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

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 :

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

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

[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" ?

[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.

[tir0nik]

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

Code :

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

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.

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.

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 :

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

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 :

||=== 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

[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

[tir0nik]

Aussi j'ai essayé le debugger sous vista et là... Aucun bug niet, rien qui plante, par contre dès que je lance en "normal" tout plante.

[Arzar]

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 ?

[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.

[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.

[tir0nik]

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 :

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

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

[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).