Memory-Leak in TObjectList??

[EConvertError]

Hallo!

Ich habe gerade eine sehr seltsame Erscheinung:
Und zwar möchte ich die TObjectList verwenden, jedoch meldet mir das Programm MemProof immer ein Memory Leak.

Ich hab mal ein leeres Projekt erzeugt und Folgendes hinzugefügt. Auch da ist das Problem existent (schöner Satz :mrgreen: ):

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
var
  List: TObjectList;
begin
  List:= TObjectList.Create(TRUE);
  List.Free;
end;

Ich benutze Delphi 7 Professional, auf Windows XP Pro.

Was kann ich da tun? Gibt es da wirklich ein Memory Leak? Kann ich jetzt die TObjectList nicht verwenden?

mfg,
EConvertError

[Bernhard Geyer]

Also ich verwende MemCheck und TOBjectList ohne Probleme. Evtl. liegt das Problem bei MemProof?

[EConvertError]

Erstmal Danke für die Antwort.

Als ich habe jetzt einmal ein ganz leeres Projekt kompiliert und mit MemProof geprüft. Das Leak taucht auch da auf!

Also liegt nicht an der TObjectList, sondern an etwas ganz anderem. Nun hoffe ich, dass es nicht an meinem Delphi liegt. Seltsamerweise hat MemProof immer gut funktioniert.
Jetzt zeigt er mir immer an, dass ein VirtualMemory mit der Größe 4096 nicht freigegeben worden ist. Und das auch bei einem Programm, das ganz sicher Memory-Leak frei ist.

Ich werd mal das MemCheck testen....

mfg,
Andy

[Keldorn]

Hallo

die 4096 sind normal, siehe hier: http://www.delphi-groups.de/YaBBSe/i...=20029;start=0 (letztes post von AHUser)

Aber ich glaube eher, das du memproof nicht richtig anwendest. Aktivier die Häkchen in den delphi-optionen, so wie es in der hilfe von memproof beschrieben ist. Dann siehst du genau, wer wirklich für ein evtl. Speicherleck verantwortlich ist.

Mfg Frank

[EConvertError]

Danke für die Antwort.

Wie meinst du das: "die 4096 sind normal"?

Ich werde daraus:

Zitat:

Das ist ein MakeObjectInstance Aufruf. Der Speicherbereich wird nie mehr freigegeben (außer nach dem Beenden durch Windows selbst). Es ist aber etwas statisches, das nur einmal reserviert wird und nicht wiederholt reserviert wird.

...nicht schlau. Sind das jetzt Leaks oder nicht? Wenn ja: Sind Delphi Programme dann unsauber?
Und wenn das normal ist: Wie ist es dann möglich, dass ich schon Programme hatte, die dieses 4096 Problem nicht hatten, und ich jetzt das Problem schon habe?

Ich habe bei meinem MemProof keine Hilfe dabei (Habs direkt von der MemProof-Seite gezogen).
Bei den Compileroptionen habe ich "Optimierung" ausgeschaltet, bzw."StackFrames" und bei "Debug" alles eingeschaltet.Weiters habe ich beim Linker noch die TD32-Infos aktiviert.
Stimmt das so?

mfg,
EConvertError

[EConvertError]

Hallo noch einmal!

Mir hat die ganze Sache keine Ruhe gelassen, und ich habe weitergeforscht. w3seek und ich haben festgestellt, dass dieses Leak wirklich auftritt und nicht mein Delphi irgendwie kaputt ist.

Jetzt habe ich folgendes gefunden (Google,http://www.elists.org/pipermail/delp...er/012626.html ):

Zitat:

> I'm MemProof-ing some of my apps, and came across a "Virtual Memory"
> leak. The code it points to is in Forms.pas, the
> MakeObjectInstance(Method: TWndMethod)
> function. The variable Block (PInstanceBlock) is not freed within the
> function.

It shouldn't be freed there. Block is being used as a temporary variable
for extending a linked list. When InstFreeList is nil, there is no more
room in the are reserved for holding object instances (InstBlockList).
InstFreeList points to the free area. Another page of memory is reserved
and tacked onto the end using Block to hold the location.

> It's been a while since I dealt with Lists (which is what this seems
> to be operating on), but isn't that correct? Isn't it that you can't
> free the pointer to the item you just added to the list?

Call FreeObjectInstance. It moves the object instance space back onto the
list of free spots.

> So. Assuming the VCL code is doing what it *should* be doing, what
> could my app have done to generate this leak? It only occurs in one
> of the apps I've proofed.

You are right: the memory is never freed. That is by design. The est you
can do is contain the memory "leak." Call FreeObjectInstance when you can.
MakeObjectInstance only allocates more memory when it runs out of its
original allocation.

As I said, this behavior is by design. The memory is never really leaked
since InstFreeList and InstBlockList are always pointing to it or to
something that points to it. The only time that memory is truly leaked is
after your program finishes, at which point Windows frees any memory for
you anyway.

--Rob

Es ist also kein richtiges Leak, sondern wird sowieso freigegeben, wenn mein Programm beendet wird. Nur was bedeutet das "FreeObjectInstance"? Wo und wann soll ich das Aufrufen?

Die zweite Sache, die ich gefunden habe, ist:

Zitat:

> The only time that memory is truly leaked is
> after your program finishes, at which point Windows frees any memory for
> you anyway.

Thanks. Odd thing, though. When I first ran MemProof on it, that
"leak" wasn't there, but others were. After I fixed the others, that
one showed up. Ah, well.

Ich bin also nicht der einzige, der diese Meldung früher nicht hatte.
Vielleicht hilft das auch jemand anderem. :-)

mfg,
EConvertError

[SirThornberry]

Komich, hab memproof grad mal auf ein etwas größeres Project angewendet welches dann auch bestimmt ne viertel Stunde geladen hat und aus irgendeinem grund bekommt memproof da nicht mit wenn ich das programm beende und somit werden auch keine memory-leaks angezeigt