Strange programme se bloquer, qu'est-ce que cela signifie dans le débogage?

Question

Un étrange programme se bloque, qu'est-ce que cela signifie dans le débogage?

Après avoir fixé windbg je trouve ce qui suit:

 
(1714.258): Access violation - code c0000005 (first chance) 
First chance exceptions are reported before any exception handling. 
This exception may be expected and handled. 
eax=015b5c74 ebx=178a13e0 ecx=dddddddd edx=009a8ca0 esi=09fbf698 edi=09fbf594 
eip=005ae2f7 esp=09fbf4a4 ebp=09fbf594 iopl=0   nv up ei ng nz na pe nc 
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000    efl=00010286 
TestApplication!std::_Container_base::_Orphan_all+0x57: 
005ae2f7 c70100000000 mov  dword ptr [ecx],0 ds:0023:dddddddd=???????? 

pile d'appel:

 
TestApplication!std::_Container_base::_Orphan_all+0x57 
TestApplication!std::vector >::operator=+0x37 
TestApplication!boost::asio::detail::win_iocp_io_service::do_one+0x189 
TestApplication!boost::asio::detail::win_iocp_io_service::run+0xa2 
TestApplication!boost::asio::io_service::run+0x3a 

Answer 1

Le problème

1. exceptions de la première chance signifie que le débogueur vous donne, la personne qui utilise le débogueur, la première chance de déboguer l'exception, avant qu'elle ne le rejette au programme gérer le problème.

2. Dans ce cas, l'exception est "Violation d'accès". Cela signifie que votre programme essaie de lire/écrire à partir d'un emplacement de mémoire illégal.

3. Les violations d'accès sont sérieuses car il pourrait corrompre de la mémoire qui est critique pour votre programme et ce serait la raison probable que votre programme se bloque. À partir de l'instruction d'erreur, il semble que vous essayez d'obtenir le contenu d'une valeur de 4 octets à partir d'une instruction illégale.

Débogage le problème

1. Si cela est votre code, vous pouvez déboguer facilement ce problème en définissant l'emplacement de symbole de débogage dans le dossier de sortie de votre compilateur (ce qui contient les fichiers pdb pertinents)

2. Lorsque vous obtenez cette exception obtenir la pile d'appel (une des fenêtres de vue, il aurait)

3. Ceci vous montrerait l'emplacement dans votre code d'origine de la pile défaillante.

4. Maintenant, ouvrez le fichier qui contient cette source et définissez un point d'arrêt là et le programme atteindrait ce point et s'arrêterait dans le windebugger. Mise au point de ce point et vous savez exactement quelle ligne de code de cette violation est jeté

Astuce: Boost est livré avec la source de sorte que vous pouvez facilement mettre un point de rupture dans ce code. Assurez-vous d'appuyer sur F11 pendant le débogage lorsque vous arrivez à asio :: detail :: win_iocp_io_service :: do_one.

Answer 2

Le registre ecx a une adresse non valide (dddddddd). Je dirais que c'est un cas de corruption de la mémoire. Pensez à activer gflags pour le processus.

Answer 3

Si vous utilisez MSVC et la configuration de génération de débogage, 0xdddddddd signifie généralement que vous tentez d'accéder à la mémoire libérée. Le gestionnaire de mémoire CRT de débogage remplit la mémoire libre avec 0xdd.

Answer 4

La callstack est entièrement un code STL/Boost. À moins que quelque chose que vous faites ne sorte de l'ordinaire, je ne vais pas supposer que le bug est dans une section de la pile d'appel que vous avez collée.

Un couple de choses à vérifier:

1. Tous Boost #defines spécifiques qui doivent être définis mais ne coûtent pas?

2. Secure SCL & Débogage d'itérateur. Essayez d'activer/désactiver.

3. Mélangez-vous le code de version & de débogage. (mauvaise idée avec les conteneurs STL/Boost)