Debugging perdite di memoria .NET - come sapere cosa contiene un riferimento a cosa?

Question

Sto lavorando su un'applicazione .NET in cui sembra che ci sia una perdita di memoria. So che il libro di testo risponde, che gli eventi devono essere annullati, gli oggetti usa e getta dovrebbero essere smaltiti ecc ...

Ho un cablaggio di prova in grado di riprodurre l'errore. Nel finalizzatore di una certa classe scrivo per consolare

public class Foo 
{ 
    // Ctor 
    public Foo() 
    { 
    } 

    ~public Foo() 
    { 
     Console.WriteLine("Foo Finalized"); 
    } 
} 

Nel test harness, sto creando una singola istanza di Foo (che a sua volta crea e interagisce con centinaia di altri tipi) quindi rimuoverlo e invocando la Netturbino.

Sto riscontrando che Foo Finalizer non viene mai chiamato. Ho una classe simile con questa configurazione che è finalizzata come test di controllo.

Quindi la mia domanda è questa:

Come è possibile determinare con strumenti di origine commerciale o aprire esattamente quello sta tenendo un riferimento alla Foo?

Ho una licenza professionale per dotTrace Memory profiler ma non riesco a capire dai file della guida come usarlo.

Aggiornamento: Ora sto usando dotMemory 4.0, che è il successore del (buono, ma inutilizzabile) dotTrace Memory 3.5.

Answer 1

Il finalizzatore non è chiamato deterministicamente, quindi attenzione di usarlo per tracciare le cose in modo affidabile. Se si rimuove il finalizzatore e si utilizza invece un WeakReference<Foo>, si dovrebbe essere in grado di determinare se l'oggetto è stato raccolto.

Tutti i profiler di memoria dovrebbero essere in grado di trovare un problema come questo, ma con un diverso grado di difficoltà. Personalmente ho usato ANTS che è molto facile da usare, ma non libero. Ti aiuterà a mostrare un diagramma di riferimento all'istanza di Foo, a partire da un oggetto radice GC. Vedendo questo diagramma è solitamente facile individuare chi detiene il riferimento.

Answer 2

È possibile utilizzare profiler di memoria per identificare le perdite di memoria. Qui ci sono alcuni,

MemProfiler

ANTS Profiler

Answer 3

Avere uno look nell'estensione SOS debugger (È gratuito, può essere utilizzato all'interno di Visual Studio).

È possibile trovare this e this utili per iniziare.

Se è stato impostato succefully SOS (questo può essere difficile a volte), sapendo ciò che contiene un riferimento a ciò che è facile come

// load sos 
.load sos 
// list of all instances of YourTypeName in memory with their method tables 
!DumpHeap -type YourTypeName 
// put here the method table displayed by the previous command 
// it will show you the memory address of the object 
!DumpHeap -mt 07f66b44    
// displays information about references the object at the specified address 
!GCRoot 02d6ec94 

Answer 4

In primo luogo non si dovrebbe usare un finalizzatore, perché:

operazioni Finalizzare presentano le seguenti limitazioni:

• il tempo esatto in cui il finalizzatore viene eseguita durante immondizia collezione non è definita. Non è garantito che le risorse vengano rilasciate in qualsiasi momento specifico di , a meno che non si chiami un metodo Close o un metodo Dispose.

• Non è possibile eseguire i finalizzatori di due oggetti in qualsiasi ordine specifico , anche se un oggetto fa riferimento all'altro. Cioè, se l'oggetto ha un riferimento all'oggetto B ed entrambi hanno i finalizzatori, l'oggetto B potrebbe essere già finalizzato all'avvio del finalizzatore dell'oggetto A.

• Il thread su cui viene eseguito il finalizzatore non è specificato.

Citato da: http://msdn.microsoft.com/en-us/library/system.object.finalize.aspx
Io suggerirei di usare metodo Dispose, invece.

In secondo luogo, qualsiasi profiler di memoria dovrebbe essere in grado di trovare ciò che contiene tali riferimenti. Personalmente stavo usando ANTS Profiler, è uno strumento molto carino e ha una documentazione abbastanza ricca. Puoi provare a leggere questo documento: http://downloads.red-gate.com/HelpPDF/ANTS_Memory_Profiler/InstanceCategorizer.pdf Il classificatore di istanze visualizza catene di riferimenti da serie di oggetti a radice GC.

Answer 5

Il debug delle perdite di memoria può essere un processo abbastanza complicato e richiede una conoscenza approfondita della logica del programma e almeno di alcuni interni .Net (in particolare il comportamento del garbage collector).

Per ulteriori informazioni consultare i seguenti link:

buona introduzione

• http://msdn.microsoft.com/en-us/library/ee658248.aspx

Hands-on corso:

• http://www.dotnetfunda.com/articles/article508.aspx
• http://www.dotnetfunda.com/articles/article524.aspx

GC e.interni netti

• http://blogs.msdn.com/b/tess/archive/2008/04/17/how-does-the-gc-work-and-what-are-the-sizes-of-the-different-generations.aspx
• http://msdn.microsoft.com/en-us/magazine/cc163491.aspx
• http://blogs.msdn.com/b/maoni/archive/2004/06/03/148029.aspx

WinDbg con estensione SOS

• http://www.codeproject.com/Articles/19490/Memory-Leak-Detection-in-NET
• http://www.simple-talk.com/dotnet/.net-framework/investigating-.net-memory-management-and-garbage-collection/

Good Luck!