malloc instable ?

**Gonath** · 31/07/2008, 18h59

Bonjour,

je viens ici pour comprendre pourquoi la fonction malloc pourrait me provoquer des erreurs d'executions.

je m'explique :

j'ai un code générant des tableaux de dimensions 1 et de dimensions 2 de manière dynamique. Ces tableaux font partis d'une classe que je nome AGO. Lors de l'utilisation du programme, je crée un objet de AGO qui crée dans son constructeur les tableaux voulus selon les dimensions passées en paramètres.

A chaque utilisation, je recrée un nouvel objet AGO. A la première utilisation, il n'y a aucun problème. A la seconde utilisation, mon programme plante. En remontant dans le code, j'ai pu constater que les lignes contenant la fonction malloc en sont responsable.

Le programme ne demande pas beaucoup de mémoire, au plus quelques ko par tableau, donc cela ne peut etre un débordement. (au fait je préviens que je suis un débutant du malloc).

donc voici les deux lignes responsables :

// on crée le vecteur de demande
v = (signed int *) malloc(sizeof(signed int)*m);

// on crée le vecteur d'erreur
e = (signed int *) malloc(sizeof(signed int)*m);

la variable m a toujours la même valeur. (donc là ce n'est pas du dynamique mais c'est juste pour vérifier si je peux faire plusieurs fois la même opération).

Le plantage est significatif après une deuxième création d'objet AGO voir parfois à la troisième ou quatrième. Par contre, avec les lignes suivantes du code :

a = (bool**) malloc(n * sizeof(bool*));
for(unsigned int i = 0; i < n; i++)
a[i] = (bool*) malloc(m * sizeof(bool));

le plantage se fait obligatoirement à la seconde fois. (la variable n est fixé).

Pourriez vous me conseillez concernant la fonction malloc etc. Cela me pose quelques problèmes pour développer et cela m'ennuie d'avoir un programme instable.

merci pour vos futures réponses !

**wiztricks** · 31/07/2008, 19h21

En général, c'est un peu plus bavard que "plante".
Ca dit quoi?
- W

**Noxen** · 31/07/2008, 19h34

malloc()/free() en C++ c'est le mal, new/delete c'est mieux

Les std::vector aussi c'est bien.

Faudrait voir quel est le message d'erreur que tu obtiens.

Avec new[] et delete[] :

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
 
#ifndef AHO_H
#define AGO_H
 
class AGO
{
private:
	int* _V;
	int size_v;
 
	int* _E;
	int size_e;
 
	bool** _A;
	int size_a1;
	int size_a2;
public:
	AGO(int v, int e, int a1, int a2):
	  _V(0), _E(0), _A(0), size_v(v), size_e(e), size_a1(a1), size_a2(a2)
	{
		_V = new int [size_v];
		for(int i = 0; i < size_v; ++i)
			_V[i] = 0;
 
		_E = new int [size_e];
		for(int i = 0; i < size_e; ++i)
			_E[i] = 0;
 
		_A = new bool*[size_a1];
		for(int i =0; i < size_a1; ++i)
		{
			_A[i] = new bool[size_a2];
			for(int j = 0; j < size_a2; ++j)
				_A[i][j] = false;
		}
	}
 
	~AGO()
	{
		for(int i = 0; i < size_a1; ++i)
			delete[] _A[i];
		delete[] _A;
 
		delete[] _E;
 
		delete[] _V;
	}
 
	/* Divers acesseurs et méthodes */
};
 
#endif

**Gonath** · 31/07/2008, 19h39

Et bien je viens juste de modifier mon code pour enlever les malloc. J'y ai donc mis des new à la place. Mais même plantage. Par contre, pour un quelconque message, je n'ai absolument rien. A part quand j'ai employé le debuggeur de wxdevcpp, il m'a mis une erreur de segmentation. (problème souvent du à des mauvais pointeurs mal gérés je suppose). Je cherche de ce coté là. Mais je ne maitrise vraiment pas le débuggeur (mea culpa).

**wiztricks** · 31/07/2008, 20h03

je suspecterais plutôt un pb côté assignation dans a et a[i] que dans malloc, mais un coup de debugger devrait régler çà
- W

**Gonath** · 31/07/2008, 20h23

Oui mais pourquoi cela marche pour la première fois, et non pour les fois suivantes ? C'est surtout cela ma question... Car tout fonctionne bien pour la première fois.

**wiztricks** · 31/07/2008, 20h30

c'est pour répondre à ce genre de questions invraisemblable qu'on a inventé les debugger

- W

**Aszarsha** · 31/07/2008, 20h35

Parce que la première fois tu tombe dans une page mémoire allouée au programme, les suivantes non ?

**Gonath** · 31/07/2008, 21h04

Lorsque j'utilise les breakpoints du debugger, donc en faisant pas à pas l'execution, il n'y a pas de problème apparemment. Il fonctionne correctement.

**wiztricks** · 31/07/2008, 21h14

Jetez les breakpoints et remplacez les par des printf des adresses d'affectations
&a[i], i, n
- W

**Gonath** · 31/07/2008, 21h15

Normalement, new doit se débrouiller pour trouver de l'espace mémoire, surtout que mon programme ne prend vraiment pas bcp (1Mo) et que j'ai suffisement de place. Donc normalement, il ne devrait pas avoir d'erreur d'allocation de mémoire.

**Davidbrcz** · 31/07/2008, 21h35

Il faudra qu'on m'explique pour continuer à utiliser new[] alors que la bonne solution à été donnée (std::vector).

**JolyLoic** · 31/07/2008, 21h44

Il est clair que la bonne solution est à base de vector. Il n'empêche qu'un malloc ne doit pas "planter" sans raisons. Un exemple complet qui reproduise le problème permettrait probablement de lui tordre le cou une bonne fois pour toute, avant de basculer vers la bonne solution l'esprit allégé.

**Gonath** · 31/07/2008, 21h58

oui mais pour un vector n'est-il pas plus lent ? ou bien il n'est lent que pour la création, après, il est bon et efficace ?

**Davidbrcz** · 31/07/2008, 22h04

Du point de vue fanatique:

std::vector c'est le bien !

A la facon yoda :

std::vector dans tes programmes tu utilisera !

Nan le vector n'est guère (pas ?) plus lent qu'un tableau brut, mais avec des dizaines de fonctions en plus.

PS: +1 à Loic.

**JolyLoic** · 31/07/2008, 22h59

Réponse courte : Non.

Réponse longue :

Il est plus lent qu'un tableau statique (mais ce n'est pas là ton cas, sinon std::tr1::array remplirait ce rôle), et peut dans certains cas être plus lent qu'un tableau variable C (pas disponible en C++, aucun équivalent en terme de performances).

Il peut dans certains cas être plus lent qu'un tableau à la C alloué dynamiquement, s'il est mal utilisé (pas de reserve alors qu'on connais dès le début la taille finale, s'il est passé par copie à une fonction, options de compilations permettant de détecter des erreurs restant dans le code final...).

Un tableau à la C alloué dynamiquement peut être plus lent s'il est mal utilisé, ce qui peut arriver facilement (mauvaise stratégie de croissance si la taille n'est pas connue dès le début (une bonne stratégie est relativement complexe à mettre en place)).

Un vector est infiniment plus souple, simple, sûr. Les dés sont largement pipés en faveur de std::vector.

**Aszarsha** · 01/08/2008, 00h21

Envoyé par JolyLoic

Les dés sont largement pipés en faveur de std::vector.

Sous entendre qu'il y a une once de hasard dans ce choix est quelque peu pervers...

**loufoque** · 01/08/2008, 00h43

malloc peut retourner un pointeur nul.
Tu ne traites évidemment pas ce cas.

**wiztricks** · 01/08/2008, 01h24

Envoyé par loufoque

malloc peut retourner un pointeur nul.
Tu ne traites évidemment pas ce cas.

Oui mais, originellement:

Code :

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

1
2
3
 a = (bool**) malloc(n * sizeof(bool*));
for(unsigned int i = 0; i < n; i++)
a[i] = (bool*) malloc(m * sizeof(bool));

le plantage se fait obligatoirement à la seconde fois. (la variable n est fixé).

Donc OK, s'il y avait des tests, nous pourrions ne pas nous poser de questions stupides, mais si nous faisons confiance à l'auteur çà plante lorsqu'on alloue a[1].
Comme n ne devrait pas être modifié, c'est "strange".
- W

**loufoque** · 01/08/2008, 14h17

C'est quoi l'intérêt de faire ça, au fait, plutôt que d'allouer un bloc contigü de n x m bools ?

malloc instable ?

C++

Discussions similaires

Partager

Partager