malloc instable ?

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 :

Citation:

---

// 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 :

Citation:

---

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 !

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

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:

---

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

---

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

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

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.

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

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

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.

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

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.

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

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

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 ?

Du point de vue fanatique:

Citation:

---

std::vector c'est le bien !

---

A la facon yoda :

Citation:

---

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.

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.

Citation:

---

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... :roll:

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

Citation:

---

Envoyé par loufoque

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

---

Oui mais, originellement:

Code:

---

1 2 3

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

---

Citation:

---

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

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 ?

Citation:

---

Envoyé par loufoque

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 ?

---

+1; et plus d'utiliser malloc dans du c++
Je parie que la vérité est ailleur :aie:
genre, à la première allocation tous ce passe nikel, j'utilise ma mémoire, mais j'ai une erreur d'indice (ou autre problème mémoire) et je modifie des zone mémoire non valide. Deuxième allocation, crash,

As tu vérifier tes accés mémoire??