Ho una piccola applicazione C++ single-threaded, compilata e collegata utilizzando Visual Studio 2005, che utilizza boost (crc, program_options e tokenizer), un'infarinatura di STL e altre intestazioni di sistema assortite./MT e/MD si arresta in modo anomalo, ma solo quando il debugger non è collegato: come eseguire il debug?
(Il suo scopo primario è quello di leggere in un .csv e generare un .dat binario personalizzato e un abbinato .h dichiarando strutture che "spiegano" il formato della dat.)
Lo strumento si blocca (violazione di accesso su NULL) quando viene eseguito all'esterno del debugger, solo in versione. Per esempio. premendo F5 non si provoca lo schianto dello strumento, Ctrl-F5 sì. Quando ho ri-connettere il debugger, ottengo questo stack:
[email protected]() + 0x26916 bytes
csv2bin.exe!malloc(unsigned int size=0x00000014) Line 163 + 0x63 bytes C
csv2bin.exe!operator new(unsigned int size=0x00000014) Line 59 + 0x8 bytes C++
>csv2bin.exe!Record::addField(const char * string=0x0034aac8) Line 62 + 0x7 bytes C++
csv2bin.exe!main(int argc=0x00000007, char * * argv=0x00343998) Line 253 C++
csv2bin.exe!__tmainCRTStartup() Line 327 + 0x12 bytes C
La linea è schiantarsi su una ripartizione po 'innocua:
pField = new NumberField(this, static_cast<NumberFieldInfo*>(pFieldInfo));
... Io non credo che abbia ha raggiunto ancora il costruttore, assegna solo la memoria prima di saltare al costruttore. Ha anche eseguito questo codice dozzine di volte nel momento in cui si blocca, di solito in una posizione coerente (ma altrimenti non sospetta).
Il problema scompare durante la compilazione con/MTd o/MDd (debug runtime) e viene ripristinato quando si utilizza/MT o/MD.
Il NULL viene caricato dallo stack e posso vederlo in memoria. _RtlAllocateHeap @ 12 + 0x26916 byte sembra uno enorme offset, come se fosse stato effettuato un salto errato.
Ho provato _HAS_ITERATOR_DEBUGGING in una build di debug e che non ha sollevato nulla di sospetto.
Eliminazione di un HeapValidate all'inizio e alla fine di Record :: addField mostra un heap OK fino a quando si arresta in modo anomalo.
Questo funzionava - non sono del tutto sicuro di cosa sia cambiato tra l'ora e l'ultima volta che abbiamo compilato lo strumento (probabilmente anni fa, forse con un VS precedente). Abbiamo provato una versione precedente di boost (1,36 vs 1,38).
Prima di tornare all'indagine manuale del codice o inviarlo a PC-Lint e a sfogliare l'output, qualsiasi suggerimento su come eseguire il debug in modo efficace?
[sarò felice di aggiornare la questione con più informazioni, se richiesta informazioni nei commenti.]
una volta ho avuto la gioia di semi-reverse ingegnerizzare le cose RtlHeap per un bug simile. Non essere confuso dalle enormi compensazioni - è normale. I simboli di debug (che sembrano utilizzare) mancano apparentemente di alcune funzioni private (probabilmente dichiarate "statiche" nel file sorgente) e ottenere enormi offset per RtlAllocateHeap o RtlAllocateHeapSlowly significa semplicemente che era il simbolo più vicino trovato. – arke
@arke: sì, me ne sono reso conto poco dopo aver postato la domanda. (Dovevo tornare indietro per modificarlo.) Molto prima avevo scritto uno strumento di ricerca che analizzava i file xMAP generati da Codewarrior al lavoro, e mi capitava occasionalmente la stessa cosa - semplicemente non mi è venuto in mente che non avrei Devono necessariamente avere tutti i simboli qui, per qualche ragione. – leander