Puoi avviare e interrompere il boundschecker (DevPartner)?

Question

Sto cercando di usare il boundschecker per analizzare un programma piuttosto complesso. L'esecuzione del programma con boundschecker è quasi troppo lenta per essere utile poiché mi ci vuole quasi un giorno per eseguire il programma fino al punto nel codice in cui sospetto che il problema esista. Qualcuno può darmi qualche idea su come ispezionare solo alcune parti del mio software usando boundschecker (DevPartner) in Visual Studio 2005?

Grazie in anticipo per tutto il tuo aiuto!

Answer 1

Ho usato BoundsChecker l'ultima volta qualche anno fa e ho avuto gli stessi problemi. Con progetti di grandi dimensioni, fa funzionare tutto così lentamente che è inutile. Abbiamo finito per abbandonarlo.

Ma avevamo ancora bisogno di alcune delle sue funzionalità, ma come te, non per l'intero programma. Quindi abbiamo dovuto farlo da soli.

Nel nostro caso, l'abbiamo usato principalmente per cercare di rintracciare le perdite di memoria. Se anche questo è il tuo obiettivo, ci sono altre opzioni.

1. Visual Studio fa un ottimo lavoro nel parlarti delle perdite di memoria quando il tuo programma esce
2. Segnala le perdite nell'ordine in cui sono state create
3. Ti dirà esattamente dove è stata creata la memoria trapelata se i tuoi file sorgente hanno questo in alto

#ifdef _DEBUG
#undef THIS_FILE
static char THIS_FILE[]=__FILE__;
#define new DEBUG_NEW
#endif

Questi aiutano molto, ma spesso non bastano. L'aggiunta di quel frammento ovunque non è sempre fattibile. Se usi le classi di fabbrica, sapere dove è stata allocata la memoria non aiuta affatto. Quindi, quando tutto il resto fallisce, sfruttiamo il n. 2.

Aggiungi qualcosa di simile al seguente:

#define LEAK(str) {char *s = (char*)malloc(100); strcpy(s, str);}

Quindi, aggiungi il tuo codice con " LEAK (" leak1 "); " o qualunque altra cosa. Esegui il programma ed esci. Le nuove stringhe trapelate verranno visualizzate nel dump delle perdite di Visual Studio che circonda le perdite esistenti. Continua ad aggiungere / spostare le tue dichiarazioni LEAK e rieseguire il programma per restringere la ricerca fino a quando non hai individuato la posizione esatta. Quindi correggi la perdita, rimuovi le perdite di debug e sei pronto!

Answer 2

BoundsChecker tiene traccia di tutte le allocazioni di memoria e le versioni in modo estremamente dettagliato. Sa, per esempio, che tale e tale allocazione di memoria è stata fatta dall'heap di runtime C, che a sua volta è stato preso da un heap Win32, che a sua volta ha dato vita alla memoria allocata da VirtualAlloc. Se l'applicazione è stata strumentata (FinalCheck), contiene anche informazioni dettagliate su quali puntatori fanno riferimento alla memoria.

Questo è uno dei motivi (di molti) per cui la cosa è lenta.

Se BC si connettesse a un'applicazione in ritardo, non avrebbe nessuno di questi dati accumulati e avrebbe (1) scavare tutto in una volta o (2) iniziare a indovinare qualcosa. Nessuna soluzione è molto pratica.

Answer 3

Un modo per alleggerire BoundsChecker è escludere dalla strumentazione tutti tranne i pochi moduli che ti interessano. So che non è eccezionale perché se sapessi dove si trovava la perdita non avresti bisogno di BoundsChecker. Quello che di solito raccomando è di usare prima la modalità Active Check di BC con solo il tracciamento della memoria disponibile. Ti mancano le convalide dell'API ma puoi sempre rieseguirlo separatamente. Dopo aver eseguito Active Check e ottenuto indizi su quali moduli tendano ad essere problematici, solo allora abiliti la strumentazione per il modulo o i moduli di interesse e le loro dipendenze. Sappiamo che Final Check è fastidiosamente lento, ma come afferma correttamente Mistiano, con Final Check non solo BC mantiene un grafico di tutti i blocchi allocati ma anche di tutti i puntatori e contesti. Qui sta la magia nel modo in cui Final Check può inchiodare perdite e corruzioni al momento dell'evento, non solo in caso di arresto dell'applicazione o errore. Spina senza vergogna: lavoro nel team DevPartner. Rilasciamo DPS 10.5 il 4 febbraio 2011 con supporto per applicazioni x64 in BC. A differenza del BC64 relativamente antico e sottovenduto per Itanium che forniva solo Active Check, DPS 10.5 offre il supporto completo di Final Check per applicazioni x64, sia per C ++ puro che per moduli nativi in ??esecuzione in processi .NET. Vedi microfocus.com in MF Developer per i dettagli.