Wie benutzt man MadExcept Memory Leak Detection?

[DieDolly]

Ich werde noch verrückt. Ich habe MadExcept installiert aber es wird mir nichts angezeigt wenn ich mein Testprogramm mit einem absichtlichem Memory Leak beende.
Ich habe in einer großen Komponente die nicht von mir ist einen Memory Leak den ich aber nicht finde. ReportMemoryLeaks möchte ich aber auch nicht abschalten, aber die Meldung nervt mich.

Wie mache ich mit madExcept ein Memory Leak ausfindig?

- ein Settings Window wie es in der Hilfe steht habe ich keins.
- ich soll "active error search" aktivieren, ohne Settings Window geht das aber nicht

Wenn ich das hier in die uses meiner dpr schreibe und dann speichere, verschwinden die Zeilen einfach wieder

Delphi-Quellcode:

madExcept,
 madLinkDisAsm,
 madListHardware,
 madListProcesses,
 madListModules,

[Renate Schaaf]

Versuch mal madExcept settings unter project.

[hoika]

Hallo,
nimm MadExcept wieder raus und binde FastMM4 ein.
Die weitere Benutzung siehe Google oder hier die Suche.

[Daniel]

madExcept kann das schon, das setzt aber eine korrekte Installation voraus - die sich auch in die IDE integriert. Wie oben angemerkt im Menü "Projekt".
Danach hilft die Hilfe:

http://help.madshi.net/madExceptSettings1.htm
und
http://help.madshi.net/DebugMm.htm

[DieDolly]

Jetzt klappt es endlich! Aber ich glaube das ist zu kompliziert für mich. Ein 2x TNamespace zeigt mir die Delphi-IDE als Leak an. madExcept zeigt es hier an mit "TNamespace.Create".

Delphi-Quellcode:

constructor TNamespace.Create(PIDL: PItemIdList; AParent: TNamespace);
{ Pass the PIDL of a Namespace Object Folder to create along with its parent    }
{ to create a new TNamespace.                                                   }
begin
  inherited Create;

  FParent := AParent;
  FShellCache.Data.SmallIcon := -1;
  FShellCache.Data.SmallOpenIcon := -1;
  FShellCache.Data.OverlayIndex := -1;
  FShellCache.Data.OverlayIconIndex := -1;
  IconCache := -1;
  Include(FStates, nsShellDetailsSupported);  // Be optomistic
  Include(FStates, nsShellFolder2Supported);  // Be optomistic
  Include(FStates, nsShellOverlaySupported);  // Be optomistic
  FreePIDLOnDestroy := True;
  FNamespaceID := SHELL_NAMESPACE_ID;
  { It is the Root Folder since it has no parent }
  if not Assigned(AParent) then
  begin
    { Either a nil for PID or if the PID is the Desktop PIDL means a full tree }
    if not Assigned(PIDL) or PIDLMgr.IsDesktopFolder(PIDL) then
    begin
      { If PID is already assigned then use it }
      if not Assigned(PIDL) then
        SHGetSpecialFolderLocation(ParentWnd, CSIDL_DESKTOP, FRelativePIDL)
      else
        FRelativePIDL := PIDL;
      FAbsolutePIDL := FRelativePIDL;
    end else
    { The PIDL is the Root PIDL but is NOT the Desktop namespace  it is a }
    { FULLY QUALIFIED PIDL to a namespace that is to be the Root.         }
    begin
      FAbsolutePIDL := PIDL;
      FRelativePIDL := PIDLMgr.GetPointerToLastID(FAbsolutePIDL);
    end;
  end else
  { If the folder is a child of the desktop special conditions apply see above }
  if PIDLMgr.IsDesktopFolder(AParent.AbsolutePIDL) then
  begin
    FRelativePIDL := PIDL;
    FAbsolutePIDL := PIDL;
  end else
  { Normal building of the PIDLs and Shells }
  begin
    FAbsolutePIDL := PIDLMgr.AppendPIDL(AParent.FAbsolutePIDL, PIDL);
    FRelativePIDL := PIDLMgr.GetPointerToLastID(FAbsolutePIDL);
    PIDLMgr.FreePIDL(PIDL);
  end;
end;

Kann man die Delphi-eigene Memory-Leak-Funktion nicht für gewisse Units ausschalten, fürs restliche Projekt aber behalten?

[himitsu]

Zitat:

Zitat von DieDolly (Beitrag 1483497)

Kann man die Delphi-eigene Memory-Leak-Funktion nicht für gewisse Units ausschalten, fürs restliche Projekt aber behalten?

Nein,

aber man kann "bekannte" Leaks ignorieren lassen.
RegisterExpectedMemoryLeak

[DieDolly]

Klingt kompliziert. Der obige Code sagt bei ReportMemoryLeaks "TNameSpace 2x".
Wie genau muss ich dann RegisterExpectedMemoryLeak nutzen?

Ich habe überall wo ein := TNameSpace.Create vorkommt einfach die neue Instanz eine Zeile danach in ein RegisterExpectedMemoryLeak() gepackt. Der Leak ist noch immer da.

[Renate Schaaf]

In welchem Projekt kommen denn bei dir die Leaks? Ist es eine der Demos? Dann würde ich auch mal testen. Ich benutze VirtualShellTools schon eine ganze Weile, und diese TNamespace-Leaks sind bei mir auch immer mal vorgekommen. Wenn es bei 2 bleibt, kann man das wirklich getrost ignorieren. In letzter Zeit sind die Leaks bei mir aber nicht mehr aufgetreten. Allerdings benutze ich die Variante von PyScripter auf Git-Hub.

[DieDolly]

Der Leak ist in der Demo "Explorer CheckBoxes" sowie "CheckBoxes".
Ich benutze die neueste Version von TVirtualExplorerTreeView und TVirtualExplorerListView. Der Leak ist nur da, wenn letzteres auf dem Formular ist.
Der Download kommt von MustangpeakVirtualshellTools und der Leak selber ist in der Datei MPShellUtilitis. pyscripter hat soweit ich das sehen kann keinen eigenen Fork. https://github.com/TurboPack/Mustang...etwork/members

[hoika]

Hallo,
und zumindestens FastMM4 zeigt dir die beiden Stellen an,
wo das TNameSpace erzeugt wird.

[Renate Schaaf]

Hallo,

Eine Stelle habe ich gefunden in VirtualExplorerTree (siehe ///!!!):

Delphi-Quellcode:

procedure TCustomVirtualExplorerTree.RebuildRootNamespace;
{ This will call InitNode for the root which will look at the FRootFolderNamespace }
{ and rebuild with that as its root after clearing the tree.                       }
var
  NewNodeData: PNodeData;
begin
  if (RebuildRootNamespaceCount = 0) and ShellNotifyManager.OkToDispatch then
  begin
    if not (csLoading in ComponentState) and Assigned(FRootFolderNamespace) then
    begin
      if Active then
      begin
        BeginUpdate;
        try
          if ThreadedImagesEnabled then
            GlobalThreadManager.FlushMessageCache(Self, TID_ICON);
          if ThreadedExpandMarkEnabled then
            ExpandMarkThreadManager.FlushMessageCache(Self, TID_EXPANDMARK);

          // Stupid, clear AFTER flushing! July 8, 2008
          Clear;

          if not(toHideRootFolder in TreeOptions.VETFolderOptions) then
          begin
            NewNodeData := InternalData(RootNode);
            FreeAndNil(NewNodeData.Namespace);
            RootNodeCount := 1;
          end else
          begin
            NewNodeData := InternalData(RootNode);
            if Assigned(NewNodeData) then
            begin
              FreeAndNil(NewNodeData.Namespace);
              NewNodeData.Namespace := TNamespace.Create(PIDLMgr.CopyPIDL(FRootFolderNamespace.AbsolutePIDL), nil);
              //////////!!!!!!!!!!!!!!!!!!!!!!
              RegisterExpectedMemoryLeak(NewNodeData.Namespace);
              /////////!!!!!!!!!!!!!!!!!!!!!!!
              ExpandNamespaceFolder(RootNode);
            end
          end;
        finally
          EndUpdate;
          FocusedNode := GetFirst;
          ChangeLinkDispatch;
          DoRootRebuild
        end;
      end
    end
  end
end;

Die 2 Namespaces werden nicht freigegeben sowie man irgendwo einen VirtualExplorerListView benutzt.

Den 2. hab ich nicht gefunden, MadExcept finde ich da etwas kryptisch. FastMM4 werde ich nicht benutzen, es hat mir schon einmal was zerschossen. Hoffe, das bringt dich etwas weiter.

[TurboMagic]

Naja, die eigentliche Ursache wird so aber nicht beseitigt.
Die Frage ist, wenn das wo erzeugt wird, dann muss es ja auch irgendwo wieder freigegeben werden.
Tut das diese externe Bibliothek?

[himitsu]

Jupp, eigentlich wäre die Lösung das Speicherleckt zu beseitigen ... drum gibt es ja auch die Suchfunktionen für Lecks.


Nur z.B. bei den Indy ist ein "Leck" drin, weil die in dem ganzen Multithreade es nicht geschafft haben etwas freizugeben. (sie fanden keine gute Stelle dafür)
Aber weil sie es nicht beseitigt bekammen, haben sie es dann wenigstens registriert, damit wir es nicht sehen. (es nicht ständig gemeldet bekommen)

[Renate Schaaf]

@TurboMagic

Hast du den source code von dem Ding mal angeguckt? Also, ich kann nicht sehen, wo das nicht wieder freigegeben wird. Leider hat sich scheints der ursprüngliche Autor von der Entwicklung zurückgezogen.

@himitsu

Was für Suchfunktionen kann man denn benutzen, um die Stelle zu sehen, wo der Speicher am Ende noch besetzt ist? Bei madExcept kriegt man ganz oben so threads..