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

StackOverflow https://stackoverflow.com/questions/226577

  •  03-07-2019
  •  | 
  •  

Question

Étrange programme bloqué, qu'est-ce que cela signifie en débogage?

Après avoir attaché windbg, j'ai trouvé 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'appels: 

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
Était-ce utile?

La solution

Le problème

  1. Les exceptions de première chance signifient que le débogueur vous donne, en tant que personne utilisant le débogueur, la première chance de déboguer l'exception, avant qu'elle ne soit renvoyée au programme pour gérer le problème.

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

  3. Les violations d'accès sont graves, car elles pourraient corrompre une partie de la mémoire, essentielle pour votre programme, ce qui est probablement la raison pour laquelle votre programme se bloque.

  4. D'après l'instruction défaillante, il semble que vous tentiez d'obtenir le contenu d'une valeur de 4 octets à partir d'une instruction non conforme.

Déboguer le problème

  1. S'il s'agit de votre code, vous pouvez facilement résoudre ce problème en définissant l'emplacement du symbole de débogage dans le dossier de sortie de votre compilateur (cela contiendrait les fichiers pdb pertinents)

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

  3. Ceci vous montrerait l'emplacement dans votre code d'où provient la pile défaillante.

  4. Ouvrez maintenant le fichier contenant cette source et définissez un point d'arrêt à cet endroit. Le programme atteindrait ce point et s'arrêterait à l'intérieur du windebugger. Déboguer à partir de ce point et vous saurez exactement à partir de quelle ligne de code cette violation est renvoyée

Astuce: Boost est fourni avec la source afin que vous puissiez facilement insérer un point de rupture dans ce code. Veillez à appuyer sur F11 lors du débogage lorsque vous accédez à asio :: detail :: win_iocp_io_service :: do_one.

Autres conseils

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

Le registre ecx a une adresse invalide (dddddddd). Je suggérerais qu'il s'agisse d'un cas de corruption de mémoire. Pensez à activer gflags pour le processus.

La pile d'appels est entièrement du code STL / Boost. À moins que quelque chose que vous fassiez ne sort de l'ordinaire, je ne supposerai pas que le bogue se trouve dans une section de la pile d'appels que vous avez collée.

Quelques points à vérifier:

  1. Toutes les définitions spécifiques à Boost qui doivent être définies mais qui ne sont pas?

  2. Secure SCL & amp; Iterator débogage. Essayez de l'activer / de le désactiver.

  3. Mélangez-vous debug & amp; code de version. (mauvaise idée avec les conteneurs STL / Boost)

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top