Sapere dove viene allocata la memoria tramite FastMM

Question

Sto cercando di eseguire il debug dell'utilizzo della memoria in un'applicazione di grandi dimensioni utilizzando Delphi 7. Sono stato in grado di installare fastmm debug dll completo e con esso risolvere alcuni problemi di perdita.

Ho anche installato il tracker di utilizzo della memoria, permettendomi di vedere quali blocchi sono stati assegnati e di quale dimensione sono.

La mia domanda è, c'è un modo per scoprire dove sono stati assegnati i blocchi? So che è possibile perché se la memoria non è stata liberata viene stampata una traccia dello stack. C'è un modo per "colpire" a fastmm per far sì che stampi la traccia dello stack per una determinata allocazione?

Domanda laterale: se l'indirizzo iniziale di un'allocazione è noto, c'è un modo per scoprire quale classe è l'oggetto? (supponendo che l'allocazione fosse per un oggetto

Answer 1

È possibile:

• tenta di utilizzare LogAllocatedBlocksToFile procedura. Se il parametro ALastAllocationGroupToLog è inferiore a AFirstAllocationGroupToLog o è pari a zero, vengono registrati tutti i blocchi insieme ai relativi stack di allocazione. Tuttavia, se la tua app ha molte allocazioni di memoria, preparati a lunghe attese. Ho sperimentato circa 4 ore di attesa e 1,5 GB di file risultante.(Nota: utilizzare glogg per visualizzare file di grandi dimensioni)
• modificare FastMM4.pas in modo che l'interfaccia LogCallStack sia visibile nell'interfaccia. Oppure puoi provare ad utilizzarlo direttamente da FastMM_FullDebugMode.dll

Nella domanda a lato: prova a utilizzare la funzione DetectClassInstance.

Answer 2

Se si utilizza FullDebugMode e si abilitano i condizionali che scriveranno i dati su un file, allora si dovrebbe ottenere esattamente ciò che si richiede. Scriverà una traccia dello stack per ogni allocazione trapelata quando il programma si arresta. (Se esegui il debug di un programma con molte perdite di memoria, questo può richiedere un po 'di tempo. Sembra che gli spegnimenti durino per 10 minuti o più se l'elemento che perde è un contenitore che contiene molti altri oggetti.)

Answer 3

Considerando che hai detto in un commento che la memoria dell'app viene ripulita correttamente dalla chiusura dell'app, per me sembra che stai cercando perdite di memoria logiche - in altre parole: oggetti che sono vivi più tempo del necessario b Quando arrivano i tempi per finire l'app vengono puliti perché esiste il codice per pulirli.

Esempio:

• Creare un TForm utilizzando l'applicazione come proprietario e la variabile che fa riferimento è quella globale che Delphi crea quando si crea l'unità del modulo.
• Config CloseAction del form per Cahide (in caso OnClose)
• Mostrare la forma, operano su di esso
• chiudere il modulo e mai più utilizzarlo fino a quando l'applicazione si chiude
• Chiudere l'applicazione, il che rende Application Cancella tutti gli oggetti di sua proprietà

in modo da avere una memoria logica perdita ma non un memoria fisica perdita - che è il tipo che FastMM può facilmente rilevare. Dal momento che non hai inteso che il nostro ipotetico TForm vivi fino alla fine dell'applicazione, semanticamente trapelato, ma dal momento che è referenziato e c'è un codice che lo distrugge alla fine dell'applicazione, a FastMM è un'allocazione normale.

Detto questo, non è necessario il dump della memoria del gestore della memoria, ma un profiler di memoria.