Announcement

**Bernhard Geyer** · 29.08.2005, 13:10

Wie w�re es wenn Du mal TD32-Debug-Infos zu deinem Projekt kompilieren w�rdest ...

**Peter Wolf** · 29.08.2005, 14:08

Hallo Bernhard,

danke f�r den Hinweis, aber das habe ich schon (die Gr�sse der Exe steigt von ca. 1,7 MB auf 9,7 MB).
Habe noch folgende Einstellungen:
Erster Eintrag in der DPR hinter USES ist MemCheck;
weiter unten erster Eintrag nach begin ist MemChk;
Unter den Projektoptionen beim Linker habe ich TD32... angeklickt. (MAP-Datei> Aus; Linker-Ausgabe> DCUs erz.; Speichergr��en> $00004000 $00100000 $00400000)
Unter Compiler:
Codeerzeugung> Stack-Frames; Syntaxoptionen> Strenge Pr�fung..., Erweiterter Syntax, Offene Parameter, Huge-Strings; Laufzeitfehler> Bereichspr�fung, I/O-Pr�fung, �berlaufpr�fung; Debuggen> Debug-Infos, Lokale Symbole, Referenzinfo inkl.Nur Defs, Assertion

Die Hauptform wird noch ohne Fehler erzeugt, aber sobald die n�chste Form mit Application.CreateForm(TForm4, Form4) erzeugt werden soll, hagelt es nur so von Exceptions/Zugriffsverletzungen.
Gr�sse Pete

**Heiko Luettge** · 29.08.2005, 14:25

Hallo Peter,
viell. hast du ja eine zu alte Version. 
Memcheck hat f�r jede Delphi-Version eine "optimierte" Version.
 
Kommt die Exception direkt zur Laufzeit oder nach dem Beenden des Programms ?

Ich hatte damals auch Probleme, weil ich vorher halt memcheck nicht benutzt hatte. er hat mir dann ein "paar" Lecks angezeigt.

Externe Debugsysmbole (D6) sollten auch angeklickt sein. 
Wen du mit "bei Sprachexceptions anhalten" arbeitest, zeigt dir memcheck genau die Stelle an, wo die Exception erzeugt wird.

Heik

**Bernhard Geyer** · 29.08.2005, 14:53

Auch alle Compiler-Optimierungen ausgeschaltet und Projekt komplett neu erzeugt?

> Memcheck hat f�r jede Delphi-Version eine "optimierte" Version.

Es gibt nur eine Version. Die neueren Versionen k�nnen auch mit alten Delphi-Versionen arbeiten.

> Externe Debugsysmbole (D6) sollten auch angeklickt sein.

Nicht n�tig. Geht mit TD32-Debug-Infos problemlos.

Aktuell bin ich auf <a href="http://sourceforge.net/projects/fastmm/">FastMM</a> gewechselt. Hat noch ein paar andere Vorteile f�rs Debuggen. Man erkennt sofort auch wenn man auf schon freigegebene Objekte/Speicher zugreif

**Peter Wolf** · 29.08.2005, 15:03

Hallo Heiko,

danke, Du hast mir geholfen. Ich meine, dass es zwar erst vor kurzem war, als ich MemCheck "gezogen" habe, aber es gibt jetzt die Version 2.73 (hatte 2.70), mit der dieses Problem nicht auftritt.
Hab aber schon wieder etwas gelernt:
Bevor ich etwas �ber Drittsoftware poste, erst mal nachsehen, ob es eine neue Version gibt.

Gr�sse Pete

**Peter Wolf** · 29.08.2005, 17:55

Hallo Bernhard,

habe jetzt erst Deinen Beitrag bemerkt. FastMM4.XX habe ich heute auch schon mehrmals in diversen Foren gelesen und geladen. Nur weiss ich nicht, wie ich damit umgehen soll. Ich habe nur die BorlndMM.pas im BIN-Verzeichnis ausgetauscht, aber wie man damit Speicherl�cher aufsp�rt konnte ich nirgendwo entdecken.
Aber manchmal sieht man ja den Wald vor lauter B�ume nicht.
Hast Du einen Link bzw. Tutorial f�r FastMM? Oder kannst Du es bitte kurz beschreiben? Vielen Dank im Voraus! Gr�sse Pete

**Peter Wolf** · 29.08.2005, 18:06

Ach ja, noch etwas.
Bin jetzt gerade beim s�ubern meines Codes bez�glich Speicherl�cher. Musste feststellen, dass MemCheck u.a. eine kommerziell gekaufte Komponente als Verursacher ausmacht. Gehe ich im Quelltext auf die besagte Stelle, wird aber im Quelltext der Kompo ordnungsgem�ss im Destruktor das jeweilige Objekt mit FREE freigegeben.
Hat hier MemCheck einen Fehler?
Andererseits w�rde dies auch erkl�ren, warum nach zwei Wochen ununterbrochener Laufzeit das Programm lt. Taskmanager von 9 MB auf 80 MB gewachsen ist.
Genauer gesagt handelt es sich um die SFTP-Kompos von EldoS (wobei ich jetzt EldoS nicht 100%-ig f�r das Problem verantwortlich machen m�chte). Anmerkung: Das Programm f�hrt alle 2 Min. einen SFTP-Transfer aus, wahrscheinlich deswegen auch der immense Anstieg.
Nutzt noch jemand anderes diese Kompos und hat vieleicht �hnliche Probleme?

Gr�sse Pete

**Bernhard Geyer** · 29.08.2005, 19:38

> Hast Du einen Link bzw. Tutorial f�r FastMM?

Alle Hilfe steht in der Pas und der Include-datei

> Hat hier MemCheck einen Fehler?

Nein. Vermutlich wird die Komponente intern irgendwelche Objekte/Speicherbereiche nicht korrekt freigeben die es w�hrend des Transfers anfordert

**Peter Wolf** · 29.08.2005, 21:17

Hallo Bernhard,
danke f�r Deine Antwort. Na, dann bleibt mir nichts anderes �brig, als die PAS- und INC-Dateien durchzusehen ;o))))
<
Auszug aus der MemCheck-Ergebnisdatei:
call stack - 0 : Module SBSftpCommon.pas Routine @Sbsftpcommon@TElSftpFileAttributes@Create Line 548 Find error: 004E8B4A

Und jetzt der Auszug aus der Quelldatei:
constructor TElSftpFileAttributes.Create;
begin
inherited;
FIncludedAttributes := [];
FACEs := TList.Create;
FExtendedAttributes := TList.Create; //Das ist die Zeile 548
end;

destructor TElSftpFileAttributes.Destroy;
begin
ClearACEs;
FACEs.Free;
ClearExtendedAttributes;
FExtendedAttributes.Free;
inherited;
end;

Es wird doch sauber FExtendedAttributes wieder freigegeben.
In dem ClearExtendedAttributes steht dann nochmal (auszugsweise) das
for i := 0 to FExtendedAttributes.Count - 1 do
TSBSftpExtendedAttribute(FExtendedAttributes.Items[i]).Free;
FExtendedAttributes.Clear;

F�r mich sieht das ganz gut aus, oder habe ich einen Gedankenfehler?
>

Kann noch jemand weiterhelfen? Danke!
Gr�sse Pete

**Bernhard Geyer** · 30.08.2005, 07:28

Werden auch nicht mehr TElSftpFileAttributes erzeugt als zum schlu� wieder freigegeben.
Was wird sonst im Code mit FExtendedAttributes gemacht. Evtl. gibt es ja irgendwo einen direkten FExtendedAttributes.Clear-Aufruf

**Peter Wolf** · 30.08.2005, 13:03

Hallo Bernhard,

ich habe jetzt bei EldoS das Problem per Mail geschildert und warte mal ab. Ich habe EldoS die Logdatei zukommen lassen, die ausgespuckt wurde, als ich mit ihrem Beispielprojekt einen SFTP-Transfer durchf�hrte.
Werde das Ergebnis noch posten, wenn ich es erhalte.

Gr�sse Pete

**Peter Wolf** · 31.08.2005, 06:57

Hallo Bernhard,

Du hattest nat�rlich recht mit "...Werden auch nicht mehr TElSftpFileAttributes erzeugt als zum schlu� wieder freigegeben."
Nur dass die (Mehr-)Erzeugung von TElSftpFileAttributes eben nicht in der Unit der Kompo war, sondern in meinem Projekt bzw. auch in dem Beispielprojekt "SimpleSftpDemo.dpr" von EldoS (habe hier auch noch mit MemCheck gepr�ft -> gleicher Fehler).
EldoS hat �brigens gestern gegen 17.00 mit der L�sung geantwortet:
<
Thank you very much for your information.

We have investigated the problem and came to the following conclusion. The
problem really does exist, but it is a problem not of SecureBlackbox
classes, but of incorrect usage of them. The leaks are caused by
ElSftpFileInfo objects returned by ElSimpleSftpClient.ReadDirectory event.
These objects are not destroyed by ElSimpleSftpClient and *must* be freed by
user application.

It is our fault, since we did not describe this in documentation, and the
objects are not freed in the demo application. We are very sorry for this
inconvenience.

Adding the following line to the TfrmMain.Refresh function of the
SimpleSftpDemo will prevent the leak:
------cut------
...
for I := 0 to dirList.Count - 1 do
begin
Info := TElSftpFileInfo.Create;
TElSftpFileInfo(dirList.Items[I]).CopyTo(Info);
// the following line must be added:
TElSftpFileInfo(dirList.Items[I]).Free;
Item := lvFiles.Items.Add;
...
------cut------

Once again, thank you for pointing us at this problem.
>

Gr�sse Pete

Announcement

Problem beim Auswerten von MemCheck

Problem beim Auswerten von MemCheck

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment