Maintenant, je débobile un projet important, qui a une corruption de pile: l'application échoue.
Je voudrais savoir comment trouver (débogage) Code de corruption de pile avec Visual Studio 2010?
Voici un exemple de code qui provoque des problèmes de pile, comment trouverais-je des cas moins évidents de ce type de corruption? Veuillez noter que ce n'est qu'un exemple. J'ai besoin de trouver ce mauvais code dans le projet actuel. mise à jour
3 Réponses :
Ceci est UB: Vous pouvez accéder à P avec l'opérateur Pour le trouver, vous devriez déboguer votre application et trouver où il se bloque, et j'espère que ce sera à un endroit où quelque chose est en fait faux. p [-2] = 100;
[] dans ceci ( p [i] ), mais dans ce cas i est un valeur invalide. Donc p [-2] pointe vers un emplacement de mémoire invalide et provoque un comportement non défini.
En vérité, vous pouvez utiliser [] sur des points de pointe sur des objets non-réseau: ils sont traités comme des pointeurs sur des tableaux d'un seul élément. Bien sûr, un tableau d'un élément n'a pas d'index -2.
Est-ce que cela répond à la question de l'OP?
Je pense que l'OP doit formuler sa question un peu mieux, pas sûr de ce qu'il demande.
Je crois que vos questions citaient un exemple de corruption de pile et la question que vous demandez n'est pas la raison pour laquelle il se bloque.
Si tel est le cas, il se bloque parce qu'il crée un comportement Pour répondre à la question sur le profilage de votre application: -2 pointe vers un emplacement de mémoire inconnu.
Vous pouvez utiliser Rational purify plus pour Visual Studio pour vérifier les dérogations de mémoire et erreurs d'accès.
Merci, mais selon wiki Il ne prend pas en charge pour Visual Studio 2010.
Il y a une technique qui peut être très efficace avec ces types de bugs, mais cela ne fonctionnera que sur un sous-ensemble d'entre eux qui a quelques caractéristiques:
Notez que la deuxième condition peut sembler improbable à première vue, car la pile peut être utilisée de différentes manières, en fonction des actions d'exécution. Cependant, l'utilisation de la pile est généralement assez déterministe. Le problème est qu'un emplacement de pile particulier peut être utilisé pour tant de choses différentes que le problème est vraiment un élément n ° 3.
Quoi qu'il en soit, si votre bogue a ces caractéristiques, vous devez identifier l'adresse de pile (ou l'une d'entre elles) qui est corrompue, puis définissez un point d'arrêt de mémoire pour une écriture à cette adresse avec une condition qui ne la fait briser que si le La valeur écrite est la valeur de corruption. Dans Visual Studio, vous pouvez le faire en créant un "nouveau point de rupture de données ..." dans la fenêtre de points d'arrêt, puis en cliquant avec droit sur le point d'arrêt pour régler la condition.
Si vous finissez par avoir trop de faux positifs, cela pourrait aider à réduire la portée du point d'arrêt en le laissant désactivé jusqu'à ce que certains points du chemin d'exécution soient plus proches du bogue (si vous pouvez identifier un tel moment), ou Définissez le nombre de personnes suffisamment haut pour éliminer la plupart des faux positifs.
Une complication supplémentaire est l'adresse de la pile peut passer de la course à exécuter - dans ce cas, vous devrez veiller à définir le point d'arrêt à chaque exécution (les bits inférieurs de l'adresse doivent être identiques).
Quel est l'exemple de code? Demandez-vous pourquoi cela corrompt la pile?
Vous devrez vous faufiler sur le problème, StealthTy, donc cela ne vous voit pas. Cela peut être beaucoup de travail. Mais essentiellement, courir encore et encore se rapprocher et plus près du point où de mauvaises choses se produisent. L'ajout de relevés de trace peut vous aider beaucoup.
L'option / RTC ajoute du code de débogage pour diagnostiquer les problèmes de pile. Je doute que cela va attraper ce bogue, il ne détruit pas le cadre de la pile.
Habituellement Débogou Un problème dans Un code censé fonctionner afin de déterminer ce qui ne va pas. Cependant, je ne fais toutefois pas de temps de débogage d'un code que je connais avec certitude qu'il est absolument faux et ne devrait pas travailler. Mais si c'est à des fins éducatives, allez-y et expérimentez le code brisé. :)
Normalement, un projet de débogage a déjà le / RTC1 actif ...
@Xanatos, je viens d'essayer / RTC1, cela ne montre rien sur la question.
@Serge dans ce code il protège -1, +1, +2 :-)
Note latérale: L'exemple de code ne déclencherait pas la corruption de pile. La pile devient descendre.