Memory Leak bei INDY 10 in der SMTP Komponente?

[xaromz]

Hallo,

Zitat von emsländer:

Ich HASSE Leaks in einem Produktivsystem

Tja, in diesem Fall gilt: Friss oder stirb. Die INDYs sind nun mal so geschrieben. Du kannst ja versuchen, den Leak zu stopfen, aber das könnte wohl Seiteneffekte mit sich bringen.

Gruß
xaromz

[emsländer]

Zitat von xaromz:

Hallo,

Zitat von emsländer:

Ich HASSE Leaks in einem Produktivsystem

Tja, in diesem Fall gilt: Friss oder stirb. Die INDYs sind nun mal so geschrieben. Du kannst ja versuchen, den Leak zu stopfen, aber das könnte wohl Seiteneffekte mit sich bringen.

Gruß
xaromz

Ich werds beobachten .....


Gruss

EL

[himitsu]

Zitat von xaromz:

Das ist eine Meldung vom Memorymanager FastMEM, welcher in Delphi 2006 eingebaut ist.

FastMM (dazu gibt's auch massig hier in der DP )

[markusj]

oder MemCheck, welches dir bei eingeschalteten Debuginfos sogar die stelle Anzeigt, bei der das Leak entstanden ist, mitsamt dem kompletten Aufruf-Stack.

mfG

Markus

[jbg]

Zitat von xaromz:

Tja, in diesem Fall gilt: Friss oder stirb. Die INDYs sind nun mal so geschrieben. Du kannst ja versuchen, den Leak zu stopfen, aber das könnte wohl Seiteneffekte mit sich bringen.

Also ich habe noch keinen Seiteneffekt gefunden, und diese CriticalSection wird bei mir freigegeben (Änderung am Quellcode vor fast einem Jahr), weil sie beim Entwickeln einfach nur stört.

[xaromz]

Hallo,

Zitat von jbg:

Also ich habe noch keinen Seiteneffekt gefunden, und diese CriticalSection wird bei mir freigegeben (Änderung am Quellcode vor fast einem Jahr), weil sie beim Entwickeln einfach nur stört.

Mir fliegt dann ein Assertion Error um die Ohren. Aber das lässt sich einfach beheben.

Gruß
xaromz

[emsländer]

Zitat von jbg:

Zitat von xaromz:

Tja, in diesem Fall gilt: Friss oder stirb. Die INDYs sind nun mal so geschrieben. Du kannst ja versuchen, den Leak zu stopfen, aber das könnte wohl Seiteneffekte mit sich bringen.

Also ich habe noch keinen Seiteneffekt gefunden, und diese CriticalSection wird bei mir freigegeben (Änderung am Quellcode vor fast einem Jahr), weil sie beim Entwickeln einfach nur stört.

Kannst Du uns diese Änderung bitte mal mitteilen?


Gruss

EL

[jbg]

Datei IdComponent.pas

Delphi-Quellcode:

destructor TIdComponent.Destroy;
begin
  inherited Destroy;
  // After inherited - do at last possible moment
+ if Assigned(GStackCriticalSection) then
    GStackCriticalSection.Acquire; 
  try
    Dec(GInstanceCount);
    if GInstanceCount = 0 then begin
      // This CS will guarantee that during the FreeAndNil nobody will try to use
      // or construct GStack
      FreeAndNil(GStack);
    end;
  finally 
+   if Assigned(GStackCriticalSection) then
      GStackCriticalSection.Release;
  end;
end;

...

initialization
  GStackCriticalSection := TCriticalSection.Create;
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
- // FreeAndNil(GStackCriticalSection);
+ FreeAndNil(GStackCriticalSection);
end.

Das die beim schreiben des Kommentars nicht gleich darauf gekommen sind Aber der Indy-Code ist sowieso etwas undurchsichtig (von der Formatierung mal abgesehen)

[jbg]

Ach ja und dann:

dcc32.exe -U..\..\lib -R..\..\lib -M -$D- IdComponent.pas
move IdComponent.dcu ..\..\lib

dcc32.exe -U..\..\lib -R..\..\lib -M -$D+ IdComponent.pas
move IdComponent.dcu ..\..\lib\debug

Das Indy-Package muss, wenn man es nutzt, auch neu gebaut werden.

[emsländer]

Zitat von jbg:

Ach ja und dann:

dcc32.exe -U..\..\lib -R..\..\lib -M -$D- IdComponent.pas
move IdComponent.dcu ..\..\lib

dcc32.exe -U..\..\lib -R..\..\lib -M -$D+ IdComponent.pas
move IdComponent.dcu ..\..\lib\debug

Das Indy-Package muss, wenn man es nutzt, auch neu gebaut werden.

Das bringt mir beim Compilieren mit D2006 aber nur Fehler


Gruss

EL