Votre question

[C++] Vérfication d'allocation mémoire

Tags :
  • Microsoft
  • Programmation
Dernière réponse : dans Programmation
26 Octobre 2007 11:33:10

Bonjour,

le sujet n'est pas très simple.

J'ai un code en C++, que je soupçonne de merder grave la mémoire : dépassement de tableau, affectation louche avec des cast, des memcopy, tout ça.

L'exécution à partie en C++ ne détecte pas problème mémoire, alors que manifestement, il y en a.
Un petit exemple de gorritude qui "ne plante pas" :
  1. double nbDonQQplot[1];
  2.  
  3. nbDonQQplot[1]=0;


Je voudrais savoir s'il existe des outils, des lib ou d'autres "trucs" qui permettent soit de monitorer le schmilblick, soit d'interdire et de peter directement une erreur dès qu'une telle goritude est faite.

L'environnement est sous Windows Visual C++ 6.

Les réponses du genre :
- passe sous linux
- microsoft c'est de la merde
- ahahah bien fait pour ta gueule

seront refusé.

Autres pages sur : verfication allocation memoire

26 Octobre 2007 12:12:51

Salut,

En visual C++ , tu peux utiliser une exécution pas à pas, et voir ou ton code plante.

En plus, avec ton extrait de code, on ne peut pas te dire grand chose! :) 

double nbDonQQplot[1];
nbDonQQplot[1]=0;

Taille 1 : [0]
Taille 2 : [0][1]

etc ...

Tableau de taille 1 =====> essaye plutot d'écrire dans nbdonQQplot[0]

et donc effectivement la , tu a 1 depassement memoire ...... HOUUUUUUUUUUUUUUUUUU le core dump !!!!


PS:

Record battu pour moi hier: 3500 Erreurs/warning de compilation avec un source de 300 lignes :)  :)  ......





zavé oublié un ] :D 
26 Octobre 2007 12:47:28

merci, l'exécution pas à pas, je connais.
Si tu avais bien lu, ça ne plante pas, alors que ça devrait.

je cherche juste des outils qui vérifient l'allocation mémoire, afin de faire péter à l'exécution, au lieu d'une exécution genre : "non non tout va bien, mais je pourris ta mémoire".
26 Octobre 2007 15:43:11

salut, lorsqu'il y a dépassement de mémoire, ca ne plante pas automatiquement, pour que ca plante à coup sur, faut que ca écrive à un endroit résérvé.

pour en revenir au sujet, en C++, il existe des options du compilateur (gcc en tout cas) pour vérifier qu'un pointeur n'est utilisé que s'il est déclaré auparavant et qu'il n'y a pas d'utilisation "bizarre" de pointeurs, mais c'est non efficace pour des problèmes de bord du genre intervalle de tableau.
par contre, il existe des outils pour suivre l'utilisation mémoire:
http://www.automatedqa.com/downloads/aqtime/
mais je trouvais qu'il était surdimmenssioné pour juste trouver des erreurs d'intervalles (après, ca dépend le projet)

j'ai aussi vu ca sur internet, ca peut donner des pistes: http://www.compuware.com/products/devpartner/visualc.ht...
26 Octobre 2007 15:52:44

Yes!
Merci coca.
C'est le type d'outil que je cherche.
Maintenant, je vais voir si je peux les appliquer.
26 Octobre 2007 19:27:08

Vinz42 a dit :
merci, l'exécution pas à pas, je connais.
Si tu avais bien lu, ça ne plante pas, alors que ça devrait.

je cherche juste des outils qui vérifient l'allocation mémoire, afin de faire péter à l'exécution, au lieu d'une exécution genre : "non non tout va bien, mais je pourris ta mémoire".



gniii ?
t'es bien agressif ......
a b L Programmation
26 Octobre 2007 20:33:53

Pour vérifier les memory leak d'un programme, on peut surcharger les opérateur "new" et "delete" (par exemple en mode debug uniquement) pour mémoriser tous les pointeurs alloués et désalloués, et afficher un rapport de fuites mémoire en fin. J'imagine que des libs existent. Tu peux aussi le chercher à le faire toi-même, c'est pas du gros dev ;) 
Sinon pour le tableaux, tu peux l'encapsuler dans une classe (tiens, voilà une bonne utilisation des templates :D  ) ou faire des macros de vérification, mais avec les macros, tu ne garantis pas son utilisation partout. Beaucoup de développeurs ont développé des lib pour ça (je pense par exemple aux smart pointers).
Pour ce qui est des casts, je ne vois que le problème du downcasting, mais comme là, il faut utiliser l'opérateur dynamic_cast (qui retourne le pointeur nul si le downcast n'est pas possible), en pratique, aucun cast ne devrait poser problème.
26 Octobre 2007 20:46:05

pour ce qui est des tableaux, il existe déjà des classes tels std::vector ou std::list
a b L Programmation
26 Octobre 2007 21:13:52

Oui vive la STL :)  , et d'ailleurs, il vaut mieux utiliser ça plutôt que de réinventer la roue ;) 

Sinon, pour vérifier le tableau dynamiquement, il faut de toutes façons ajouter du code, puisqu'il n'y a pas de limitation en assembleur. Pour les tableaux statique, peut-être que de la métaprogrammation par templates pour vérrouiller la compilation lorsque ça sort du tableau, est possible, mais le code ne deviendrait pas très lisible :D 
26 Octobre 2007 21:48:35

elendilm a dit :
gniii ?
t'es bien agressif ......

je vois pas... enfin bref.
CRicky a dit :
Pour vérifier les memory leak d'un programme, on peut surcharger les opérateur "new" et "delete" (par exemple en mode debug uniquement) pour mémoriser tous les pointeurs alloués et désalloués, et afficher un rapport de fuites mémoire en fin. J'imagine que des libs existent. Tu peux aussi le chercher à le faire toi-même, c'est pas du gros dev ;) 
Sinon pour le tableaux, tu peux l'encapsuler dans une classe (tiens, voilà une bonne utilisation des templates :D  ) ou faire des macros de vérification, mais avec les macros, tu ne garantis pas son utilisation partout. Beaucoup de développeurs ont développé des lib pour ça (je pense par exemple aux smart pointers).
Pour ce qui est des casts, je ne vois que le problème du downcasting, mais comme là, il faut utiliser l'opérateur dynamic_cast (qui retourne le pointeur nul si le downcast n'est pas possible), en pratique, aucun cast ne devrait poser problème.

ok. merci cricky.
alors je prend l'encapsulation et les smart pointer.
pour le reste, ça ne s'applique à mon projet.
coca25 a dit :
pour ce qui est des tableaux, il existe déjà des classes tels std::vector ou std::list

alors, le problème, c'est qu'on utilise des types simples, car le code C++ est compilé en dll pour être attaqué en C#.
Donc on a limité les paramètres d'entrée et sortie aux types simples.
Et ce sont ces paramètres qui posent problèmes.

Le reste est encapsulé avec de la vérification.

Merci à tous.
a b L Programmation
27 Octobre 2007 13:13:32

tu utilises des composants COM pour la partie C++?
27 Octobre 2007 13:40:25

heu... je crois pas.
le truc, c'est que c'est pas mon code, et pas ma spécialité le C++.
mais que je dois l'utiliser en tant que moteur de calcul, et que manifestement, ça envoie en l'air la mémoire.

et comme l'équipe projet responsable de la dll dit : "c'est pas nous, c'est vous. Vous devez montrer où ça plante et on corrigera" (on notera le contre-sens dans leur discours....), du coup, je me tape un audit du caca.

vinz est super content....
a b L Programmation
27 Octobre 2007 14:07:05

Ok, quand tu dis "ça envoie en l'air la mémoire", tu veux dire que ça crash ?
Si c'est le cas, as-tu déjà identifié l'endroit où ça crash (je veux dire, là où l'exception se soulève) ?
27 Octobre 2007 23:20:46

non, ça ne crash pas.

le problème, c'est que le C++ baise la mémoire, mais sans le dire. Du coups, c'est quand je le récupère dans le C# que je me vautre.

mais ça vautre pile au niveau de l'appel DLL.

De toute façon, on ne met pas en oeuvre les outils de vérif mémoire avant la semaine prochaine. donc j'aurais pas de nouveau avant.
27 Octobre 2007 23:27:40

Vinz42 a dit :

mais ça vautre pile au niveau de l'appel DLL.

ca, ce n'est pas forcément significatif, surtout pour des problèmes d'adressage/accès/... mémoire, le problème peut très bien être en amont (je dis pas que c'est ton cas :) )
27 Octobre 2007 23:33:49

oui, c'est en amont.

je reprend parce que j'ai peut-être pas été clair.

j'ai une dll en c++ que j'appel en C# avec un dllimport.

j'ai des appel qui plante aléatoirement, et lorsque j'ai une trace d'erreur, ça pointe sur l'appel de la dll.

on a fait des test en C++ pur, et là, le C++ ne plante pas, alors qu'il le devrait, au moins pour un dépassement de tableau.

Donc oui, les erreurs sont au niveau du C++
a b L Programmation
28 Octobre 2007 10:59:22

Citation :
on a fait des test en C++ pur, et là, le C++ ne plante pas, alors qu'il le devrait, au moins pour un dépassement de tableau.

Une fois le programme chargé en mémoire, ça dépend de ce que tu as en mémoire après le tableau quelque soit le langage utilisé. C'est l'OS qui génère l'exception.

Sinon, si c'est une erreur de pile (où on t'indique explicitement une erreur de pile, ou que ça plante en début ou fin de fonction), c'est certainement plus une erreur de passage de paramètre. C'est à dire que la fonction attend une certaine taille pour les paramètres passés par la pile, et c'est une autre taille qui est effectivement donné.

21 Janvier 2010 23:31:42

Controler les accés à la pile est un problème délicat à bien des égards. Soit on fait de l'analyse syntaxique de code, soit on surcharge le code avec tout un tas de balise spour enrichir les traitements et mettre en exergues les problèmes.

Dans tout les cas le problème du dépassement de tableau alloué sur la stack est délicat car cela écrase la variable qui à été alloué ou push juste aprés la déclaration du tableau... ca veux dire que cela peux trés bien passé inapercue en modifiant des données ou littéralement planter en changeant des valeurs de la mécanique C++ disposés dans la stack.

Cédric
www.memspell.com
Tom's guide dans le monde
  • Allemagne
  • Italie
  • Irlande
  • Royaume Uni
  • Etats Unis
Suivre Tom's Guide
Inscrivez-vous à la Newsletter
  • ajouter à twitter
  • ajouter à facebook
  • ajouter un flux RSS