manipulation de std::vector probleme memoire

**angediablo** · 28/07/2006, 19h56

Bonjour a tous!

Je suis confronte a de serieux problemes avec la manipulation des std::vector en c++ avec Visual .Net 2003. J' ai developpe un algorithme qui doit gerer des listes d objets assez complexes j utilise donc des vector pour les stocker.

Jusque la pas trop de probleme mais par la suite j ai tente d integrer mon algorithme a un autre projet que j ai adapte et les methodes communiquent par le biais de std::vector< std::vector<int> > de maniere iterative. Mais mon programme fini par s arreter pour cause de probleme de memoire de ce type:

Microsoft C++ exception: std::bad_alloc @ 0x0012ecac.

Y a t-il un probleme connu avec le fait d envoyer d envoyer en parametres des pointeurs sur des std::vector et de retourner des objets de type std::vector par le biais de methodes d'objet ou de methode statique.

Voici un exemple de code contenue dans une methode appele de facon iterative:

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
        std::vector<int> mvRef;
	int num4x4Blocks = width/4*height/4;
	blocks4x4.reserve(num4x4Blocks);
	mvRef.reserve(2*num4x4Blocks);
 
        //
        //
        // Insertion des valeurs dans mvRef a l'aide de differentes
        // methodes
        //
        //
 
 
        return mvRef;    // Ceci cree une erreur de type memory a la 2 eme
                              // iteration

Notez qu'il suffit de modifier un bout de code pour que l erreur apparaissent dans une autre methode qui a le meme genre de procede

Toutes vos suggestions sont les bienvenues...

**Laurent Gomila** · 28/07/2006, 20h06

Que vaut num4x4Blocks avant le plantage ?

**roulious** · 28/07/2006, 20h49

Envoyé par angediablo

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
        std::vector<int> mvRef;
	int num4x4Blocks = width/4*height/4;
	blocks4x4.reserve(num4x4Blocks);
	mvRef.reserve(2*num4x4Blocks);
 
        //
        //
        // Insertion des valeurs dans mvRef a l'aide de differentes
        // methodes
        //
        //
 
 
        return mvRef;    // Ceci cree une erreur de type memory a la 2 eme
                              // iteration

Quelles sont ces "differentes méthodes" ?

Si ce n'est que des méthodes d'insertion (type push_back) pas de problème. Si tu essaye d'accéder directement à un élément, il peut y avoir problème : reserve n'initialise pas les éléments supplémentaires, il ne change que la capacité du vecteur et pas sa taille.

**angediablo** · 28/07/2006, 23h13

num4x4Blocks est une variable qui ne change jamais apres l'affectation precisee elle vaut 12'288.

Et seul un push back est effectue sur mvRef. De cette facon:

for (int i=0; i<num4x4Blocks; i++)
{
int v0 = blocks4x4[i]->motionVector[0];
int v1 = blocks4x4[i]->motionVector[1];
mvRef.push_back(v0);
mvRef.push_back(v1);
}

// ou blocks4x4 est un sdt::vector<Block> , Block est une classe de mon
// programme qui possede differentes instances dont int[2] motionVector

Mais je precise que ce n est qu a une certaine iteration que l appelle a

return mvRef;

engendre une erreur de memoire

**borisd** · 29/07/2006, 02h32

De quelle taille est chaque objet Block ? Si tu en crées 12288 avec 100Ko chacun, tu atteinds plus d'1Go de mémoire... Si une copie de mvRef est faite en quittant la procédure avant que blocks4x4 soit désalloué, c'est peut-être la goutte d'eau qui fait déborder le vase ? Les Block sont-ils correctement désalloués après la première itération ?

**angediablo** · 29/07/2006, 14h58

Oui avant de retourner mvRef j effectue un blocks4x4.clear() qui vide le vecteur d'objet de type Block, et par la meme occasion desalloue la memoire reservee pour blocks4x4 n'est-ce pas?

**Laurent Gomila** · 29/07/2006, 15h33

Envoyé par angediablo

Oui avant de retourner mvRef j effectue un blocks4x4.clear() qui vide le vecteur d'objet de type Block, et par la meme occasion desalloue la memoire reservee pour blocks4x4 n'est-ce pas?

Non, la mémoire est toujours allouée. Mais ça ne devrait pas poser plus de problème que ça.

Au cas où, si tu veux vraiment essayer de vider physiquement ton tableau, tu peux utiliser ce code à la place du clear() :

Code :

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

sdt::vector<Block>().Swap(blocks4x4);

Tu peux aussi tenter d'utiliser un std::deque, qui a la même interface publique que std::vector mais qui est moins contraint au niveau de l'allocation mémoire.

**angediablo** · 29/07/2006, 17h27

Ok et bien il parait que l'appel a clear() vide le vecteur mais ne supprime pas les objets contenus a l interieur lorsque ces derniers sont des pointeurs comme dans mon cas. J'ai donc supprime les pointeur avec un delete mais le meme probleme est apparu a la meme iteration lors d un appel a new voici les details:

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
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
 
 
std::vector<int> Multigrid::methodeMultigrid16x16(unsigned char* I_Y,      unsigned char* P_Y, unsigned char* prediction, unsigned char* predictionBlocks, unsigned char* blocksMap, int step, int width,int height, int precision, unsigned int* complexity, unsigned char* prediction4x4)
{
	int num128x128Blocks = width/128*height/128;
 
	int numLevels = log10(double(128/(precision)))/log10(2.0)+1;
 
	int maxNumBlocks = num128x128Blocks;
 
	int add = num128x128Blocks;
 
	for (int i=0; i<numLevels-1; i++)
	{
		add = 4*add;
		maxNumBlocks = maxNumBlocks + add;
	}
	int count=0;
 
	std::vector<Block*> blocks;
	blocks.reserve(maxNumBlocks);
 
	for (int i=0; i<maxNumBlocks; i++)
	{
		Block* block = new Block(); //------->ENDROIT DU CRASH
		blocks.push_back(block);
	}
 
 
 
	Block::process(I_Y, P_Y, &count, step, width, height, &numLevels, complexity, blocks);
 
	// Block vector for mapping
	std::vector<Block*> blocks4x4;
 
	std::vector<int> mvRef;
	int num4x4Blocks = width/4*height/4;
	blocks4x4.reserve(num4x4Blocks);
	mvRef.reserve(2*num4x4Blocks);
 
	for (int i=0; i<num4x4Blocks; i++)
	{
		Block* block = new Block();
		blocks4x4.push_back(block);
	}
 
	//Mapping multigrid Blocks to 4x4 blocks
	Block::mappingBlocks4x4(&count,blocks4x4, blocks);
	Multigrid::constructMultigridPrediction(I_Y, prediction,count, predictionBlocks, blocksMap,blocks);
	Multigrid::constructPrediction4x4(I_Y, prediction4x4, num4x4Blocks, blocks4x4);
 
	for ( std::vector<Block*>::iterator it = blocks.begin() ; it != blocks.end(); ++it) 
	{
			delete *it;
	}
 
	blocks.clear();
 
 
	//Inserting motion vectors in the motion Vector list
 
	for (int i=0; i<num4x4Blocks; i++)
	{
		int v0 = blocks4x4[i]->motionVector[0];
		int v1 = blocks4x4[i]->motionVector[1];
		mvRef.push_back(v0);
		mvRef.push_back(v1);
	}
 
 
 
	for ( std::vector<Block*>::iterator it = blocks4x4.begin() ; it != blocks4x4.end(); ++it) 
	{
			delete *it;
	}
 
 
 
	blocks4x4.clear();
 
 
 
	return mvRef;
 
 
}

Ainsi que les derniers call stack du mode debug:

Code :

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

1
2
3
4
5
6
7
8
9
 
 
 	kernel32.dll!7c81eb33() 	
 	kernel32.dll!7c81eb33() 	
 	msvcr71d.dll!_nh_malloc_dbg(unsigned int nSize=1, int nhFlag=3, int nBlockUse=1240264, const char * szFileName=0x0012ee50, int nLine=1240724)  Line 267 + 0x7	C
 	msvcr71d.dll!_CxxThrowException(void * pExceptionObject=0x0012ece4, const _s__ThrowInfo * pThrowInfo=0x104f6150)  + 0x39	C++
 	msvcp71d.dll!std::_Nomemory()  Line 10	C++
>	H264AVCEncoderLibTestStaticd.exe!operator new(unsigned int size=60)  Line 15	C++
 	H264AVCEncoderLibTestStaticd.exe!Multigrid::methodeMultigrid16x16(unsigned char * I_Y=0x06e89ff8, unsigned char * P_Y=0x04d7e028, unsigned char * prediction=0x06eba038, unsigned char * predictionBlocks=0x06eea078, unsigned char * blocksMap=0x06f1a0b8, int step=16, int width=512, int height=384, int precision=4, unsigned int * complexity=0x0012eee4, unsigned char * prediction4x4=0x06f4a0f8)  Line 84 + 0x7	C++

Et l'endroit ou le programme crash suite a l'appel a new():

Code :

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

1
2
3
4
5
6
7
8
9
10
 
 
void *__cdecl operator new(size_t size) _THROW1(_STD bad_alloc)
	{	// try to allocate size bytes
	void *p;
	while ((p = malloc(size)) == 0)
		if (_callnewh(size) == 0)
			_STD _Nomemory();
	return (p); //--------------> ENDROIT DU CRASH!!!!!!!!!!!!
	}

**Laurent Gomila** · 29/07/2006, 18h23

Ok et bien il parait que l'appel a clear() vide le vecteur mais ne supprime pas les objets contenus a l interieur lorsque ces derniers sont des pointeurs comme dans mon cas

Oui, il n'est pas censé savoir que tu stockes des variables que tu as allouées avec new... Il vide la mémoire qu'il alloue lui-même, ce qui n'est déjà pas mal.
Bref il faut bien que tu libères ce que tu alloues avec new. D'ailleurs ces allocations sont-elles nécessaires ?

**Matthieu Brucher** · 29/07/2006, 18h28

Si ça plante sur le new Block, c'est une erreur dans le constructeur.

**Laurent Gomila** · 29/07/2006, 18h39

Envoyé par Miles

Si ça plante sur le new Block, c'est une erreur dans le constructeur.

Hum... Si ça renvoie un bad_alloc et que le debugger s'arrête dans la définition de l'opérateur new, alors ça peut difficilement être le constructeur de l'objet qui a levé une exception

C'est l'allocation de mémoire qui a échoué, et c'est certainement dû à la gestion approximative de celle-ci.

**angediablo** · 29/07/2006, 18h59

Ca je veux bien te croire. Plus habitue au language Java, je suis plutot nouvel utilisateur du language c++ et donc pas habitue a devoir gerer la memoire. Et effectivement ce n est pas le constructeur qui leve l exception no_memory

**Matthieu Brucher** · 29/07/2006, 19h20

C'est vrai... Quel est le niveau d'occupation mémoire global ? Est-ce qu'il y a des allocations mémoire dans le constructeur ? Avec un fonctionnement pas à pas, qui lève l'exception ?

**angediablo** · 29/07/2006, 19h58

Le niveau d occupation memoire n est que de 67M environ avant le crash.
Et non il n'y a pas d allocution memoire de type new() dans le constructeur

**angediablo** · 29/07/2006, 20h07

Comme ecrit precedemment l'exception est levee par l'operateur new

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
 
 
void *__cdecl operator new(size_t size) _THROW1(_STD bad_alloc)
	{	// try to allocate size bytes
	void *p;
	while ((p = malloc(size)) == 0)
		if (_callnewh(size) == 0)
			_STD _Nomemory();
	return (p);
	}

ou size vaut 60 lors du crash. Durant la boucle _STD _Nomemory() est atteint

**Matthieu Brucher** · 29/07/2006, 21h37

Très très bizarre...

**angediablo** · 29/07/2006, 23h34

J'ai modifier mon code en ne passant que des references cette fois-ci et non pas des copies de vecteurs comme je le faisait avant mais l erreur de memoire est revenue au niveau du

return mvRef;

mais a la 1ere iteration cette fois ci. C est a ni rien comprendre!!!!!!!

**JolyLoic** · 30/07/2006, 01h13

Une question : Comment as-tu mesuré l'occupation mémoire ?

**angediablo** · 30/07/2006, 19h09

j ai juste regardé la valeur indiquée dans le gestionnaire de tâches

**angediablo** · 03/08/2006, 19h06

Finalement je me suis resigne a utilier un tableau de pointeurs a la place des vecteurs car meme n utilisant que du referencement ( c est a dire en ne transmettant jamais une copie d un objet envoye en parametre a une methode mais plutot la reference de ce dernier) et ca plante moins facilement. Mais comme mon programme est engage dans un boucle qui devrais selon les cas atteindre jusqu a un maximum de 1000 iterations environ, Je fini tout de meme par avoir un runtime error et mon programme se voit forcer d etre interrompu par le system. Pourtant ma contribution n est qu un plug in a un soft qui tourne deja sans aucun probleme meme avec plus de 1000 iteration. Je sais que la coquille vient de mon bout de code mais ou exactement? aucune idee. Je crois avoir tout essaye. Cependant j ai remarque un phenomene bizarre: lorsque la reference a **blocks est envoye en paremetre (&blocks) a une methode qui ne fait que de lire les valeurs pointee sans en modifier aucune elles sont alteree des la fin de l execution de la methode. D'ou peut venir ce genre de phenomenes en general?

manipulation de std::vector probleme memoire

SL & STL C++

Discussions similaires

Partager

Partager