2009-08-13 2 views
7

FAstMM meldet einen Speicherleak aus einer TIdCriticalSection in IdStack.pas. Ich verstehe, dass dies ein absichtliches Leck ist, das im Code dokumentiert ist.Delphi: memoryleak in IdStack, aber wer benutzt IdStack?

Was ich nicht verstehe, ist, warum IdStack in meinem Projekt enthalten ist. Wie kann ich herausfinden, welche Einheit es einzieht?

Gibt es eine Möglichkeit, dieses Leck aus dem Bericht auszuschließen, mit der Version von fastmm, die mit Delphi 2007 geliefert wird?

UPDATE: Gibt es eine Möglichkeit, alle Pas-Dateien in einem Build zu finden?

Antwort

4

Alle Indy-Einheiten haben ein 'Id'-Präfix, also prüfen Sie, ob Sie in Ihren Verwendungsklauseln etwas davon haben.

Eine andere Möglichkeit könnte sein, einen Haltepunkt in TIdStack.create() zu platzieren. Schließlich wird der Schuldige im Call-Stack erscheinen.

+0

Ich habe versucht, Breakpoints, aber es bricht nie. Ich sehe aus, als wäre der Initialisierungs-/Finalisierungsabschnitt der einzige Code, der ausgeführt wird. Ich mache jetzt einen riesigen Grep, um zu sehen, ob ich etwas finden kann. – Vegar

+0

Ein großer Grep fand die gebrauchte Einheit! – Vegar

2

Blick auf Verwendungen in Ihrem .dpr Verwendung cnPack (cnPack.org) und wählen Sie 'Verwendet Reiniger' Einheiten entfernen nicht

verwiesen
+0

Eine andere Möglichkeit, dies zu tun, ist Icarus, eine kostenlose Teilmenge von Pascal Analyzer: http://www.peganza.com/#ICARUS –

+0

wow. Habe von cnPack gehört, habe es aber nie ausprobiert. Das muss geändert werden! :-) Vielen Dank. – Vegar

8

Der Delphi FastMM Speichermanager

function RegisterExpectedMemoryLeak(P: Pointer): boolean; 

So stellt ein Verfahren zur Wenn Sie die Einheit gefunden haben und sich herausstellt, dass Sie sie nicht entfernen können, können Sie diese Methode verwenden, um eine Speicherleckwarnung zu unterdrücken.

4

Es gibt eine Menge darüber auf dem Netz, obwohl es verstreut ist. Es hängt davon ab, ob Sie Indy 9 (mit D7) oder später verwenden. Es hat mich auch geplagt. Für 9 Indy habe ich die folgenden in IdComponent.pas:

initialization 
    GStackCriticalSection := TCriticalSection.Create; 

    // BJF Starts 
    //RegisterExpectedMemoryLeak(GStackCriticalSection); 
    // BJF Ends 

finalization 
    // Dont Free. If shutdown is from another Init section, it can cause GPF when stack 
    // tries to access it. App will kill it off anyways, so just let it leak 

    // BJF has removed comments 
    FreeAndNil(GStackCriticalSection); 
end. 

Aber beachten Sie, dass Sie einen Weg zum Indy Quelle im Bibliothekspfad setzen müssen. Ich glaube, dass Indy 10 in dieser Hinsicht fixiert ist. Brian

+0

Entfernen Sie diese Kommentare nicht. In einer Multithread-App kann es deshalb fehlschlagen. Es ist eine globale Variable, und Windows wird die Speicher- und Kernel-Handles (wie kritische Abschnitte) bei der Beendigung sowieso freigeben. Siehe diesen Link und die Artikel, auf die er verweist: http://blogs.msdn.com/b/oldnewthing/archive/2010/01/22/9951750.aspx –

Verwandte Themen