Pouvez-vous démarrer et arrêter boundschecker (DevPartner)?

Question

J'essaie d'utiliser boundschecker pour analyser un programme plutôt complexe. Exécuter le programme avec boundschecker est presque trop lent pour qu'il puisse être utile, car il me faut presque une journée pour l'exécuter jusqu'au point du code où je soupçonne que le problème existe. Quelqu'un peut-il me donner des idées sur la manière d'inspecter uniquement certaines parties de mon logiciel à l'aide de boundschecker (DevPartner) dans Visual Studio 2005?

Merci d'avance pour votre aide!

Answer 1

J'ai utilisé BoundsChecker pour la dernière fois il y a quelques années et j'ai eu les mêmes problèmes. Avec les grands projets, tout se passe si lentement que c'est inutile. Nous avons fini par l'abandonner.

Mais nous avions encore besoin de certaines fonctionnalités, mais comme vous, pas pour tout le programme. Nous avons donc dû le faire nous-mêmes.

Dans notre cas, nous l’utilisions principalement pour tenter de localiser les fuites de mémoire. Si c'est également votre objectif, il existe d'autres options.

1. Visual Studio fait un très bon travail pour vous informer des fuites de mémoire lorsque votre programme se ferme
2. Il signale les fuites dans l'ordre dans lequel elles ont été créées
3. Il vous indiquera exactement où la mémoire perdue a été créée si vos fichiers source l'ont en haut

#ifdef _DEBUG
#undef THIS_FILE
static char THIS_FILE[]=__FILE__;
#define new DEBUG_NEW
#endif

Ceux-ci aident beaucoup, mais ce n'est souvent pas suffisant. Ajouter cet extrait partout n'est pas toujours faisable. Si vous utilisez des classes d'usine, il est inutile de savoir où la mémoire a été allouée. Alors, quand tout le reste échoue, nous profitons de # 2.

Ajoutez quelque chose comme ce qui suit:

#define LEAK(str) {char *s = (char*)malloc(100); strcpy(s, str);}

Ensuite, poivrez votre code avec "LEAK (" leak1 ");" ou peu importe. Exécutez le programme et quittez-le. Vos nouvelles chaînes fuites s'afficheront dans le vidage de fuite de Visual Studio entourant les fuites existantes. Continuez à ajouter / déplacer vos instructions LEAK et à réexécuter le programme pour affiner votre recherche jusqu'à ce que vous ayez localisé l'emplacement exact. Ensuite, corrigez la fuite, supprimez vos fuites de débogage et le tour est joué!

Answer 2

BoundsChecker suit toutes les allocations de mémoire et toutes les versions de manière extrêmement détaillée. Il sait, par exemple, que telle ou telle allocation de mémoire a été effectuée à partir du tas C, qui à son tour a été extrait d'un tas Win32, qui à son tour a démarré comme mémoire allouée par VirtualAlloc. Si l'application a été instrumentée (FinalCheck), elle contient également des informations détaillées sur les pointeurs référençant la mémoire.

C’est l’une des raisons (parmi tant d’autres) pour laquelle la chose est lente.

Si BC se connectait à une application en retard, aucune de ces données ne serait accumulée et (1) déterrerait tout cela en même temps, ou (2) commencerait à deviner. Aucune solution n'est très pratique.

Answer 3

Une façon d'alléger BoundsChecker consiste à exclure de l'instrumentation tous les modules, à l'exception des quelques modules qui vous intéressent. Je sais que ce n'est pas génial, car si vous saviez où se trouvait la fuite, vous n'auriez pas besoin de BoundsChecker. Ce que je recommande habituellement, c’est d’utiliser d’abord le mode de vérification active de BC avec uniquement le suivi de mémoire disponible. Vous manquez les validations de l'API, mais vous pouvez toujours les réexécuter séparément. Une fois que vous avez exécuté Active Check et obtenu des indices sur les modules problématiques, activez l'instrument pour le ou les modules d'intérêt et leurs dépendances. Nous savons que Final Check est extrêmement lent, mais comme Mistiano l’a déclaré correctement, avec Final Check, BC conserve non seulement un graphique de tous les blocs attribués, mais également de tous les pointeurs et contextes. C’est là que réside la magie dans la façon dont Final Check peut réparer les fuites et les corruptions au moment de l’occurrence, pas seulement lors de l’arrêt de l’application ou de la défaillance. Prise sans scrupule: je travaille sur l'équipe de DevPartner. Nous publions DPS 10.5 le 4 février 2011 avec prise en charge des applications x64 en Colombie-Britannique. Contrairement au BC64 pour Itanium, relativement ancien et sous-vendu, qui fournissait uniquement Active Check, DPS 10.5 fournit une prise en charge complète de Final Check pour les applications x64, aussi bien pour le C ++ pur que pour les modules natifs s'exécutant dans des processus .NET. Voir microfocus.com sous MF Developer pour plus de détails.