2016-06-29 2 views
-3

Dans la capture d'écran suivante, vous pouvez voir le désassemblage de la fonction CString GetLength() qui provoque un plantage. Ceci est pris du fichier de dump, post mortem. L'accident est causé par un changement soudain du registre EAX à 0.Pourquoi le contenu du registre EAX a subitement changé et conduit à un plantage

Comment peut-il être que de 6A6A4547 à 6A6A4549 le registre EAX pourrait être changé. Dans 6A6A4547, il aurait dû être défini sur 0x6a8e7054 (0x38324964 {0x6a8e7054}). Vous pouvez le voir dans la fenêtre de la montre. Dans 6A6A4549 EAX est soudainement "0".

Pourquoi et comment? Puis-je savoir quelle était la cause?

informations latérales:

  • pile d'appel semble normal aucun problème dans les variables ou les discussions
  • son compilé avec le compilateur de VS2012
  • plate-forme cible est x86
  • son sur une machine virtuelle
  • programme fonctionne avec plusieurs threads
  • GetLength est appelé des millions de fois par heure

graph

+0

Et cela se produit de manière complètement aléatoire? L'avez-vous capturé en direct lors de son exécution dans un débogueur ou cette capture d'écran est-elle basée sur un vidage de mémoire? –

+1

Notez le '[eax-0ch]', en particulier la partie ** - 0ch **. Voyez ce qu'il y a dans '0x38324958'. –

+0

(int *) (0x38324958) -> 0x38324958 {0x00000000} C'est en fait la valeur correcte (c'est une chaîne vide). Le problème est que eax est 0x0000000 et au lieu de "0x38324958" la valeur "-12" est utilisée comme adresse. – Kalman

Répondre

2

Il est comme la plupart d'entre vous écrit - a race condition.

Dans une partie supérieure du logiciel, un objet n'était pas verrouillé suffisamment. EAX est donc devenu 0 dans la première ligne d'assemblage. Après cela, un autre thread "corrigé" la mémoire et il semble seulement que le registre EAX a été changé.

Comme la plupart des accidents aussi c'est fait maison.

Merci à vous tous!