Newsgroup: it.comp.programmare.win32
Titolo: [MFC] Crash fuori compilatore

In ambiente Visual Studio .NET 2003 sviluppo dei
software che gestiscono dati molto pesanti (nuvole di punti, cartografie
CAD, ecc.).
Il problema generale, che non riguarda un formato preciso di dati, č che con
compilatore in background va tutto ok, posso "stressare" quanto voglio la
macchina di turno che testa lo sviluppo. Fuori compilatore, anche nelle
stesse macchine, i software vanno in crash in circostanze random senza un
motivo ben preciso e senza ripetibilitŕ. I PC sono ben "carrozzati", č
sicuro che non soffrano la gestione di questi dati.
I report dei crash segnalano che l'eccezione di volta in volta si verifica
in moduli di Windows come ntdll.dll, o msvcr71.dll, o ancora in moduli di
librerie esterne di cui possediamo soltanto la versione compilata.
Ho googlato un casino circa a questo problema, mi pare di esser l'unico,
direi di aver cercato male. Avete qualche dritta?
Ovviamente se avete bisogno di informazioni piů dettagliate fatemi sapere,
grazie!
--
Marco
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/


Se fai uso di COM, trova un esorcista al piů presto!
Bip
-- 
Questo articolo e` stato inviato dal sito web 
http://www.nonsolonews.it

 Se fai uso di COM, trova un esorcista al più presto!
Niente esorcista allora :-)


 
In questi casi potrebbe esserti utile un "post mortem" debugger con il 
quale dovresti essere in grado di risalire alla tua ultima chiamata 
prima dello schianto. E' molto probabile che tu passi ad una funzione di 
libreria qualche handle/indirizzo sbagliato.
Personalmente me la sono sempre cavata con il semplice DrWatson abbinato 
ai simboli di debug opportunamente "strippati" dall'exe. Se ti servono 
info vedi 
http://support.microsoft.com/kb/q258205/
 o simili.
Spesso le informazioni del DRWatson sono imprecise o incomplete ma 
possono essere utili per avere un idea di dove andare a cercare. A volte 
basta un indirizzo sullo stack da abbinare ai mapfiles generati dal 
compilatore.
Comunque tanti auguri...
ciao
BB

 Comunque tanti auguri...
Eh, grazie...


Marco
Una "fattura" in meno!!!


 
Si, il call stack è riempito a casaccio, ma non proprio senza una logica....
Mi spiego meglio: gli indirizzi di ritorno sono abbastanza scazzati, ma 
all'interno dello stack trovi prima o poi qualche indirizzo che proviene 
dai tuoi moduli (lo riconosci perchè dovrebbe essere poco più grande di 
0x400000 che è il base address di default per gli exe).
Bene, partendo da quell'inidrizzo, dovresti capire abbastanza facilmente 
di quale funzione del tuo codice si tratta (questa info la puoi ricavare 
facendo dumpbin a partire dal file .dbg).
A questo punto ti consiglio di verificare (compilando il modulo che 
contiene la funzione incriminata con le opzioni per avere il listato 
assebly completo con simboli e sorgente c++) che all'indirizzo che hai 
trovato sullo stack frame corrisponda una qualche call.
Se è vero, vedi a che chiamata di alto livello corrisponde, e controlli 
se i parametri che passi sono corretti (o meglio a questo punto hai una 
vaga idea di dove incominciare a scavare per debuggare).
Ho usato più o meno questa procedura svariate decine di volte, e fin'ora 
ho sempre avuto successo!
Invece, in teoria, ci sarebbe un metodo decisamente migliore che per 
vari motivi non sono mai riuscito a sperimentare:
dovresti istruire DRWatson di creare un crash dump file (che rischia di 
essere mostruosamente grande), e a questo punto dovrebbe essere 
possibile caricare tale file in un debugger e ricostruire lo stato del 
processo come quando è morto. Di più non ti so dire ma se googli con 
"post mortem debugging" dovrebbe uscirti qualcosa.
Ti ripeto gli auguri...
Ciao
BB

Guardati anche questo
http://www.codeproject.com/debug/postmortemdebug_standalone1.asp
che potrebbe fare a caso tuo


Ci do subito un'occhiata, speriamo bene.
Grazie mille davvero per l'aiuto e l'interessamento!
-- 
Marco