Newsgroup: it.comp.programmare.win32
Titolo: qualche consiglio sul debugging

Ciao a tutti,
mi trovo a sviluppare un'applicazione su xp con "visual C++".
E ho notato una differenza prestazionale, che credo sia ben descritta 
dall'aggettivo "abissale" ;) tra versione di debug e quella di release.
E' possibile in qualche modo aumentare le prestazioni durante il debug?
Grazie
Francesco

 wrote in
news:46e905a1$0$37200$
4faf...@reader3.news.tin.it
: 

Puoi provare ad abilitare le ottimizzazioni del compilatore, ma in 
questo caso probabilmente ti perderai la corrispondenza tra sorgente 
e disassemblato, nel senso che più istruzioni C consecutive (o anche 
no!) potrebbero essere "mischiate" tra loro dal compilatore per 
migliorare l'efficenza del codice e questo ti porterà ad avere 
comportamenti strani dei breakpoint, dell'esecuzione step-by-step e 
dei watch.
In alternativa puoi provare a spezzare il tuo exe in diverse lib 
compilando mano a mano in release i pezzi che hai già debuggato.
Rimane sempre la possibilità che un bug si presenti solo in release. 
I motivi possono essere due:
- il codice viene eseguito più rapidamente e questo genera una 
condizione che in debug non si verifica
- il codice è compilato in modo diverso e questo genera un 
comportamento differente. Le differenze possono essere date da 
differenze di compilazione (#ifdef gestiti diversamente tra debug e 
release), di esecuzione (funzioni delle librerie di debug che si 
comportano diversamente dalla versione di release) o di 
ottimizzazione (l'ottimizzatore è troppo zelante e introduce 
problemi oppure il tuo codice si basava su qualche presupposto che 
in release non vale, ad esempio sul fatto che le variabili vengano 
sempre scritte subito in memoria al momento della modifica...).
Per debuggare in release puoi affidarti a due strumenti:
- trace di debug (che però rallentano e sincronizzano il codice)
- istinto (a volte quel genere di istinto che inizia per C)
In generale in caso di problemi che compaiono solo in release un 
buon approccio è quello di semplificare mano a mano il codice fino 
ad arrivare a un esempietto banale che riproduca il problema e da lì 
ragionare guardando l'assembler, giocando con le opzioni di 
compilazione etc.
-- 
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non è valido)

 E' possibile in qualche modo aumentare le prestazioni durante il debug?
No.
Se però vuoi farti del male la rispota è SI, e puoi leggerti il post di 
Valter.
Tieni conto che in debug, per esempio, ogni accesso in un punto del 
vettore con l'operatore [] è prima validato, mentre in release 
l'accesso è diretto; in debug ad una allocazione di X byte (credo) 
venga allocato in realtà x+y e poi a fine programma verificato se tu 
hai scritto in y, e così via. Tutto ciò lo puoi "disabilitare" in un 
modo o nell'altro, però lo fai a tuo rischio e pericolo.
Forse potresti prendere in considerazione la vecchia strada di 
compilare i Release, e poi andare di gran printf per il debug.
-- 
v-day video: 
http://www.radioradicale.it/scheda/234532
il capitalismo: 
http://www.rat-man.com/site/IT/IT/rat_cartoon.ashx?mn=5

Francesco ha scritto:

Aggiungo a quanto già detto nelle altre risposte:
non è detto che sia il tuo caso (anzi la tua domanda è un'altra) ma già 
che siamo a parlare di debug e release, in generale c'è un'altro aspetto 
molto importante che è il cosiddetto "post mortem debugging".
In questo caso hai un programma (tipicamente in release) che va in crash 
e vuoi innanizitutto sapere dove (o almeno circa) e se possibile 
riprodurre lo stato del processo alla morte.
Ti serve un "post mortem debugger" (il più semplice è drwatson) che 
fondamentalmente scrive da qualche parte un "dump" dei thread del tuo 
processo facendoti vedere dove è avvenuto il crash e altre info utili (a 
saperle leggere).
Se da qualche parte avevi i "simboli di debug" drwatson (a volte) è in 
grado di dirti almeno in quale funzione si trova il codice in cui è 
avvenuto il crash. Può essere molto utile.
Con XP inoltre c'è una API MiniDumpWriteDump che permette di ottenere un 
dump che è debuggabile off line con visual studio (il famoso file di 
"dettaglio arresto anomalo" da inviare al produttore del software). Per 
info vedere: 
http://www.codeproject.com/debug/postmortemdebug_standalone1.asp
Ciao
GM

 E' possibile in qualche modo aumentare le prestazioni durante il debug?
Normalmente nella configurazione di release tutto il codice e' 
ottimizzato e senza informazioni di debugging e in quella di debug tutto 
il codice non e' ottimizzato e ha le informazioni di debugging.
Potresti creare una terza configurazione partendo da quella di debug in 
cui si usano le librerie runtime di release, in cui alcuni moduli sono 
ottimizzati e altri no, e in cui tutto il codice tranne quello di 
libreria ha le informazioni di debugging.
-- 
     Carlo Milanesi
 
http://digilander.libero.it/carlmila

 
Questo e' un ottimo consiglio, io "credo" alle librerie che uso... ci 
devo credere per forza ;)
Molte Grazie!

 Hmmm non sono cosi' esperto... non so se le uso, ne' cosa siano!
Le istruzioni di tracing o di logging sono istruzioni inserite in mezzo 
al codice che emettono messaggi utili al debugging o al monitoraggio 
dell'applicazioni. Tale emissione puo' essere verso un file, o verso 
un'altra applicazione, tipicamente un debugger che le mostra in 
un'apposita finestrella.
Le verifiche di invarianti sono istruzioni che controllano che alcune 
assunzioni che il programmatore fa siano effettivamente rispettate. Per 
esempio, verificare a runtime che l'accesso a un array usi un indice 
valido, o che un puntatore dereferenziato non sia nullo.
Spesso si inseriscono entrambi i tipi di istruzioni (trace e verifiche) 
e poi si disattivano in release tramite compilazione condizionale.
