Strano blocco del programma, cosa significa questo nel debug?

Question

Strano blocco del programma, cosa significa questo nel debug?

Dopo aver collegato windbg ho trovato quanto segue:

(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=????????

Call stack:

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

Il problema

1. Eccezioni della prima possibilità significa che il debugger ti sta dando, la persona che sta usando il debugger, la prima possibilità di eseguire il debug dell'eccezione, prima che la restituisca al programma per gestire il problema.

2. In questo caso l'eccezione è " violazione di accesso " ;. Ciò significa che il tuo programma sta provando a leggere / scrivere da una posizione di memoria illegale.

3. Le violazioni dell'accesso sono gravi perché potrebbe corrompere un po 'di memoria che è fondamentale per il tuo programma e questo potrebbe essere il motivo per cui il tuo programma si blocca.

4. Dall'istruzione di errore sembra che si stia tentando di ottenere il contenuto di un valore di 4 byte da un'istruzione illegale.

Debug del problema

5. Se questo è il tuo codice, puoi facilmente eseguire il debug di questo problema impostando la posizione del simbolo di debug sulla cartella di output del tuo compilatore (conterrebbe i file pdb pertinenti)

6. Quando ottieni questa eccezione ottieni lo stack di chiamate (una delle finestre di visualizzazione l'avrebbe)

7. Questo ti mostrerebbe la posizione nel tuo codice in cui ha avuto origine lo stack difettoso.

8. Ora apri il file che contiene questa fonte e imposta lì un punto di interruzione e il programma colpirà questo punto e si fermerebbe all'interno del windebugger. Esegui il debug da questo punto e sapresti esattamente da quale riga di codice viene generata questa violazione

Suggerimento: Boost viene fornito con l'origine in modo da poter inserire facilmente un punto di interruzione all'interno di questo codice. Assicurati di premere F11 durante il debug quando arrivi ad asio :: detail :: win_iocp_io_service :: do_one.

Answer 2

Se si utilizza MSVC e la configurazione build di debug, 0xdddddddd indica in genere che si sta tentando di accedere alla memoria liberata. Il gestore della memoria CRT di debug riempie la memoria libera con 0xdd .

Answer 3

Il registro ecx ha un indirizzo non valido (dddddddd). Vorrei suggerire che questo è un caso di corruzione della memoria. Valuta di attivare gflags per il processo.

Answer 4

Il callstack è interamente codice STL / Boost. A meno che qualcosa che stai facendo sia fuori dall'ordinario, non presumo che il bug si trovi in ??qualsiasi sezione del callstack che hai incollato.

Un paio di cose da controllare:

1. Qualunque #define Boost specifico che dovrebbe essere definito ma non valido?

2. Secure SCL & amp; Debug di Iterator. Prova ad abilitarlo / disabilitarlo.

3. Stai mescolando debug & amp; codice di rilascio. (cattiva idea con i contenitori STL / Boost)