Program crasht beim Schließen, aber...

[scrat1979]

Ich hatte mal ein ähnliches Problem und bekam auf der Suche nach dem Fehler graue Haare. Ursache war letztendlich ein fehlender „override“ in der Destructor-Deklaration des selbst erstellten Objektes. Prüfe auch mal, ob überall der übergeordnete Desktruktor mittels inherited aufgerufen wird. Auch als Profi kann einem das ja mal durch die Lappen gehen... viel Erfolg!

[himitsu]

Im Delphi ist schon länger FastMM drin, aber nur in einer kleinen Version.

Außer dem einfachen MemoryLeak-Test, den man per Variable aktivieren kann, fehlt der Rest.

Beim großen FastMM kann man eben auch beim Freigeben von OLbjekten/Pointern ein Überschreiben aktivieren, was spätere Zugriffe erkennen lässt.
Normal wird Speicher ja nicht sofort freigeben und man kann nach dem Free/Destroy noch auf Einiges zugreifen, mit dem ungültigen Zeiger.

[freimatz]

Ginge das auch mit madExcept? Habe da keine Option genau dazu gefunden.

[hhcm]

Zitat von freimatz:

Ginge das auch mit madExcept? Habe da keine Option genau dazu gefunden.

Meinst du den Memory Leak test? Das geht in den MadExcept Settings unter "active error search" auf der ersten Seite "report resource leaks"

[MyRealName]

Zitat von freimatz:

Ginge das auch mit madExcept? Habe da keine Option genau dazu gefunden.

Wenn es um die Memory leaks geht, dann einfach in den basic settings schauen, ganz unten unter "report resource leaks"

[hhcm]

Zitat von MyRealName:

Wenn es um die Memory leaks geht, dann einfach in den basic settings schauen, ganz unten unter "report resource leaks"

Knappe Stunde später, gleiche Antwort.

[freimatz]

Jein. Es ging mir nicht um Memory Leaks sondern um "auf doppelt freigegebene Objekte". Das ist ja quasi das Gegenteil.

Inzwischen habe ich es wohl gefunden. Es ist die wohl Option "instantly crash on buffer overrun/underrun".

Ging bei mir leider nicht, weil es dann ein out of memory Fehler kam. Ich meinem Falle kann ich den Fehler anderweitig eingrenzen. Aber gut zu wissen.

[himitsu]

Sowas kann man per se sich auch selbst schnell bauen.
Eigentlich würde es reichen, wenn man das FreeMemory überschreibt und dort den Inhalt "zerstört", dann werden Zugriffe nach dem Free fehlschlagen.

Der wichtige Teil ist natürlich das FillMemory/FillChar.

Delphi-Quellcode:

function MyFreeMem(P: Pointer): Integer;
begin
  FillMemory(P, UnknownSize, $A5);  // 1010 0101 = HighBit + Odd
  Result := SysFreeMem(P);
end;

var
  MemMgr: TMemoryManagerEx;

initialization
  GetMemoryManager(MemMgr);
  MemMgr.FreeMem := MyFreeMem;
  SetMemoryManager(MemMgr);

finalization
  GetMemoryManager(MemMgr);
  MemMgr.FreeMem := SysFreeMem;  // oder MemMgr.FreeMem im Init speichern
  SetMemoryManager(MemMgr);

end.

Aber leider ist es nicht so einfach im FreeMem die Größe rauszubekommen.
(wäre auch zu einfach gewesen, wenn diese MemoryAPI uns den Wert direkt als Parameter geben würde )

Im Windows (wenn FastMM verwendet) könnte erstmal rausfinden in was für einem Block (SmallXXX, Medium oder Large) der Speicher liegt
und dementsprechend dann auslesen wie groß der Speicher ist (inkl. dem zusätzlichen Speicher dahinter).
Bei den Small ist die Größe bekannt und bei den Anderen steht sie (ähnlich wie hier) vor den Daten gespeichert.

In Liunx/MacOS/iOS/Android kann es nochmal anders aussehn.

Nja, also der umständlicheren Einfachheit halber einfach die Größe noch mit einfügen, um schnell und sicher den Wert vom GetMem zu bekommen.

Delphi-Quellcode:

function MyGetMem(Size: NativeInt): Pointer;
begin
  Inc(Size, SizeOf(Integer));
  Result := SysGetMem(Size);
  PInteger(Result)^ := Size;
  Inc(NativeInt(Result), SizeOf(Integer));
end;

function MyFreeMem(P: Pointer): Integer;
begin
  Dec(NativeInt(P), SizeOf(Integer));
  FillMemory(P, PInteger(P)^, $A5);  // 1010 0101 = HighBit + Odd
  Result := SysFreeMem(P);
end;

function MyReallocMem(P: Pointer; Size: NativeInt): Pointer;
begin
  Dec(NativeInt(P), SizeOf(Integer));
  Inc(Size, SizeOf(Integer));
  Result := SysReallocMem(P, Size);
  PInteger(Result)^ := Size;
  Inc(NativeInt(Result), SizeOf(Integer));
end;

function MyAllocMem(Size: NativeInt): Pointer;
begin
  Inc(Size, SizeOf(Integer));
  Result := SysAllocMem(Size);
  PInteger(Result)^ := Size;
  Inc(NativeInt(Result), SizeOf(Integer));
end;

var
  MemMgr: TMemoryManagerEx;

initialization
  GetMemoryManager(MemMgr);
  MemMgr.GetMem     := MyGetMem;
  MemMgr.FreeMem    := MyFreeMem;
  MemMgr.ReallocMem := MyReallocMem;
  MemMgr.AllocMem   := MyAllocMem;
  SetMemoryManager(MemMgr);

finalization
  GetMemoryManager(MemMgr); 
  MemMgr.GetMem     := SysGetMem;
  MemMgr.FreeMem    := SysFreeMem;
  MemMgr.ReallocMem := SysReallocMem;
  MemMgr.AllocMem   := SysAllocMem;
  SetMemoryManager(MemMgr);

end.

und nicht vergessen, dass dieses in der DPR als erste Unit im Uses sein muß

[freejay]

Zitat von scrat1979:

Ich hatte mal ein ähnliches Problem und bekam auf der Suche nach dem Fehler graue Haare. Ursache war letztendlich ein fehlender „override“ in der Destructor-Deklaration des selbst erstellten Objektes. Prüfe auch mal, ob überall der übergeordnete Desktruktor mittels inherited aufgerufen wird. Auch als Profi kann einem das ja mal durch die Lappen gehen... viel Erfolg!

Danke! Schau ich mir mal an. An sowas hätte ich nie gedacht...