Je prévois d'utiliser GCC plus (Linux et Windows) et je me demandais s'il y a un équivalent du MSVC debug heap et le STL checks disponible pour le GCC CRT et STL.Debug tas/STL débogage équivalent pour GCC?
Je connais déjà des outils tels que Valgrind, mais je cherche quelque chose construit dans les bibliothèques.
Je ne suis pas trop familier avec le tas de débogage et des contrôles STL, mais quand j'ai des problèmes de mémoire dans GCC sur linux j'utiliser une variable d'environnement appelé MALLOC_CHECK_ (de malloc (3)):
récente les versions de Linux libc (plus tard que 5.4.23) et de GNU libc (2.x) incluent une implémentation de malloc qui peut être ajustée via des variables d'environnement. Lorsque MALLOC_CHECK_ est défini, une implémentation spéciale (moins efficace) est utilisée qui est conçue pour être tolérante contre les erreurs simples, telles que les doubles appels de free() avec le même argument, ou dépassements d'un seul octet (off-by -un bug). Cependant, toutes ces erreurs ne peuvent pas être protégées contre les erreurs et des fuites de mémoire peuvent en résulter. Si MALLOC_CHECK_ est défini sur 0, toute corruption de tas détectée est ignorée silencieusement; si est défini sur 1, un diagnostic est imprimé sur stderr; Si la valeur est 2, abort() est immédiatement appelé . Cela peut être utile car sinon un crash peut arriver beaucoup plus tard, et la véritable cause du problème est alors très difficile à localiser.
Il existe également une clôture électrique qui peut aider à intercepter les dépassements de tampon dès que le dépassement/le dépassement se produit. Voir libefence(3) pour plus d'informations.
La version STLport de la bibliothèque standard à http://sourceforge.net/projects/stlport/ a un mode de débogage que j'avais l'habitude d'utiliser et qui est recommandé par Scott Meyers dans Effective STL. Je ne l'ai pas utilisé depuis plusieurs années maintenant, donc je ne peux pas garantir l'état actuel.
Il y a aussi un fil de discussion sur le débogage STL de GCC here, mais je ne peux pas encore me porter garant de l'information qu'il donne.
Merci Neil. Je préférerais vraiment ne pas remplacer la STL, parce que j'utilise des bibliothèques tierces qui ont été construites avec le STL "standard". – rpg
Malheureusement, vous devrez utiliser un ensemble différent de conteneurs STL pour obtenir la prise en charge d'une STL de débogage même si vous utilisez une implémentation de bibliothèque provenant du même fournisseur que votre bibliothèque habituelle.Je suis assez sûr qu'il n'y a pas vraiment de 'debug STL' là où l'objet ne change pas leur disposition si vous utilisez la version de débogage. Donc, à mon humble avis, vous devrez aller reconstruire tous les composants avec la même version de la bibliothèque et les mêmes drapeaux de toute façon. –
Pour autant que je sache, MSVC dispose par défaut des fonctionnalités de débogage STL, donc la version de débogage d'une bibliothèque utilisant la STL utilisera les fonctionnalités de débogage (en supposant qu'elles ne les désactivent pas explicitement - ce qui rendrait la lib avec les projets MSVC par défaut). Je pourrais faire un effort et reconstruire, mais je voudrais toujours utiliser le classique STL si possible. – rpg
Je ne les ai jamais utilisés, mais je sais que la glibc a quelques capacités pour faire du débogage de la mémoire allouée dynamiquement. Voici une entrée manuelle appropriée: http://www.gnu.org/s/libc/manual/html_node/Memory-Allocation.html#Memory-Allocation. "Allocation non contrainte" contient des informations sur les différentes manières d'accrocher les fonctions d'allocation et "Débogage d'allocation" contient des informations sur l'aptitude de la glibc à tracer les allocations.
Personnellement, je pense que Valgrind est le moyen le plus simple de le faire.
Ouais, mais je ne peux pas l'utiliser avec MinGW ... – rpg
Certains débogage tas est disponible avec ÉFENSE/DOUMA (même sous MinGW)
Qu'est-ce que vous cherchez peut être activé en définissant _GLIBCXX_DEBUG avant d'inclure les bibliothèques standard. Je ne suis pas sûr de ce que cela affectera si vous ne pouvez pas l'utiliser de manière cohérente. Mon conseil par défaut serait d'être très prudent. J'ai aussi entendu dire que les vérifications de débogage peuvent être un gros succès. Si grand qu'il est peut-être imprudent de toujours l'activer pour les versions de débogage.
C'est exactement ce que fait le tas Debug Peter, merci! Savez-vous si ces vérifications sont également effectuées pour le nouveau/supprimer? – rpg
Cela se fait dans mon implémentation (l'opérateur delete, au moins, semble avoir un appel sous-jacent à free(), donc il attrape le double-free). Clôture électrique attrape définitivement les dépassements de mémoire tampon avec la mémoire allouée par l'opérateur nouveau. –
Notez que glibc 2.10 et 2.11 sont buggué: MALLOC_CHECK_ peut provoquer des blocages et des crash de programmes multithread. – ephemient