Programm stürzt nach mehren Stunden Laufzeit ab.

[Delphi.Narium]

Damit kannst Du feststellen, wieviele Handles Dein Prozess so "verbrät".

Delphi-Quellcode:

// Je nach Delphi ist's auch schon in Winapi.Windows zu finden:
function GetProcessHandleCount(hProcess: THandle; var pdwHandleCount: DWORD): BOOL; stdcall;
  external 'kernel32.dll';

procedure LogHandles(s : String);
var
  HandleCount: DWORD;
begin
  if GetProcessHandleCount(GetCurrentProcess, HandleCount) then
    Addline_Debug(Format('%s: Handles: %d',[s, HandleCount]);
end;

Wenn Du diesen Wert regelmäßig in Deinem Programm selbst prüfst und kontrollierst (Logfile oder sowas), kannst Du damit schonmal feststellen, ob es da einen Zuwachs gibt. (Und könnte einfacher sein (da auch unbeaufsichtigt möglich), als immer vorm Taskmanager zu sitzen und zuzuschauen

Bei 'nem Mitschreiben in 'ner Log-Datei kannst Du ggfls. sehen, welcher Wert hier vor dem Programmabsturz zuletzt protokolliert wurde.

Damit kannst Du dann ggfls. schonmal eine "Schmerzgrenze" ermitteln, ab der ggfls. mit 'nem Programmabsturz zu rechnen ist.

Wenn Du diesen Wert weißt, dann ziehe davon 'nen ordentlichen Puffer ab und steuere dann über diesen Wert einen automatischen Neustart des Programmes durch sich selbst. (Shellexecute (o. ä.) der eigenen Exe und die beendet sich dann.)

Achso:

Das ist natürlich nur ein Workaround, grundsätzlich wäre eine Lokalisierung und Bereinigung des Problemes vorzuziehen. Aber wie das so ist: Oft ist diese Anforderung leichter gesagt, als im realen Leben umgesetzt

Die obige Routine kannst Du in alle Routinen, bei denen ein (unerwarteter) Handlezuwachs möglich ist, einbauen:

Delphi-Quellcode:

// Am Anfang der Unit:
{$DEFINE HandleProtokoll}
// Am Anfang der relevanten Routinen:
{$IFDEF HandleProtokoll}LogHandles('Start Name der Funktion / Prozedure / Aufgabe ...');{$ENDIF}

// Am Ende der relevanten Routinen:
{$IFDEF HandleProtokoll}LogHandles('Ende Name der Funktion / Prozedure / Aufgabe ...');{$ENDIF}

Über den Kompilerschalter kannst Du das dann recht einfach aktivieren bzw. deaktivieren, ohne jeweils groß im Quelltext Änderungen vornehmen zu müssen.

Oder halt Dein Addline_Debug direkt um die Protokollierung der Handles ergänzen.

Ein Zuwachs im Speicherverbrauch ließe sich ähnlich protokollieren und ggfls. darauf reagieren.

[gee21]

Also ich hab jetzt heute bereits ein wenig getestet. Und werde wohl in den nächsten Tagen das ganze nocheinmal ganz genau anschauen um es dann in zukünftigen projekten direkt besser machen zu können.
(Vielen Dank delphi.narium für das beispiel mit dem handles auslesen, das wird mir bestimmt helfen in den nächsten tagen und ansonsten mache ich dann im notfall wirklich einen "workaround").

Heute sind mir folgende Fragen dazu durch den Kopf gegangen:
- Passiert bei Beispiel 1 ein Fehler oder auch nicht wird die Stringlist trotzdem immer freigegeben da sie nach dem except steht?
- ist Beispiel 2 korrekter / besser? da wird die Stringlist ebenfalls immer freigegeben da Finally immer ausgeführt wird egal ob fehler oder nicht?
- Weshalb sehe im im Taskmanager das mein Programm manchmal 2-7 Threads am laufen hat? Ich arbeite doch in diesem Tool gar nicht mit Threads? kommt das von IDFTP komponente? oder was macht den "automtisch" mehrere Threads. Ich sehe auch dass es dann manchmal von zb 7 Threads wieder runter auf 3 Threads geht.

Beispiel 1:

Delphi-Quellcode:

var
ts: tstringlist;
begin
try
ts:=tstringlist.create;
 mach das 1
 mach das 2
 mach das 3
 except
 // bei einem Fehler wird nichts gemacht. fährt aber nach except weiter?  
 end; 
 ts.free;
end;

Beispiel 2:

Delphi-Quellcode:

var
ts: tstringlist;
begin
 try
 ts:=tstringlist.create;
 mach das 1
 mach das 2
 mach das 3
 finally
 //egal ob ein fehler passiert oder nicht stringlist wird wieder freigegeben.
 ts.free;
 end; 

end;

[venice2]

Verwende bitte Delphi Tags dann kann man den Quelltext besser lesen.
Danke!

Du kannst except und finally combinieren.

Im Beispiel 1 wird ts.free; Nie Aufgerufen wenn ein anderer Fehler auftritt.

Sorry eine leere Fehlerbehandlung ist ein Nonsens.

Delphi-Quellcode:

except
// bei einem Fehler wird nichts gemacht. fährt aber nach except weiter?
end;

[TomF]

Ich bin jetzt nicht so der Profi - aber müsste das ts:=tstringlist.create; nicht vor dem try stehen, damit das Sinn ergibt ?

[venice2]

Zitat von TomF:

Ich bin jetzt nicht so der Profi - aber müsste das ts:=tstringlist.create; nicht vor dem try stehen, damit das Sinn ergibt ?

Ja.

[gee21]

Anscheinend verstehe ich ziemlich viel nicht.

Beispiel 3 habe ich ebenfalls im Internet in einem toutorial geshen und habe nun begonnen dies so abzuändern. Da es wohl so einfach richtig ist

Weshalb aber soll/muss ts:=tstringlist.create; vor den try stehen? Was wäre der nachteil wenn es nach dem try steht? Grössere ressourcen verbrauch? Oder unübersichtlicher da man bei einer exception mehr zu kontrollieren hat?

Ich bin am mittwoch wieder am arbeiten. Dann werde ich alles nach besten wissen und gewissen abändern und euch genauere infos über speicherverbrauch und handles geben können.

In meinem ersten Post ist der komplette quelltext!

[Delphi.Narium]

Zitat von gee21:

Beispiel 3 habe ich ebenfalls im Internet in einem toutorial geshen und habe nun begonnen dies so abzuändern. Da es wohl so einfach richtig ist

Weshalb aber soll/muss ts:=tstringlist vor den try stehen? Was wäre der nachteil wenn es nach dem try steht? Grössere ressourcen verbrauch? Oder unübersichtlicher da man bei einer exception mehr zu kontrollieren hat?

Weil ansonsten (zumindest theoretisch) die Möglichkeit besteht, dass ts innerhalb des Try / Except bzw. Try / Finally nicht existiert. Zumindest die Kompilerwarnung wird dies aussagen.

Du arbeitest sehr viel mit globalen Variabel, das macht den Quelltext nicht unbedingt leichter les- und verstehbar. Mir ist z. B. noch nicht so ganz klar geworden, wann ts_log nun von wo welche Daten bekommt, wann sie wo unter welchen Bedingungen in die Datei geschrieben werden, ob und ggfls. wann und wie lange ts_log und Memo_log (teilweise) identischen Inhalt haben ...

Viele Deiner Prozeduren könntest Du auch zu Prozeduren des Formulars machen, dann sparst Du Dir schonmal die vielen Form1...

Wahllos rausgegriffen mit der Bitte um "grundsätzliche" Korrektur:

Delphi-Quellcode:

if tdirectory.exists(programmpfad+'LS')=false then tdirectory.CreateDirectory(programmpfad+'LS');
if tdirectory.exists(programmpfad+'RE')=false then tdirectory.CreateDirectory(programmpfad+'RE');
if tdirectory.exists(programmpfad+'ET1')=false then tdirectory.CreateDirectory(programmpfad+'ET1');
if tdirectory.exists(programmpfad+'ET2')=false then tdirectory.CreateDirectory(programmpfad+'ET2');

if form1.CheckBox_autostart.checked=true then form1.Button_start_action.Click;

...

   if ts.Strings[14]='tray:off' then form1.CheckBox_tray.Checked:=false;
   if ts.Strings[15]='autostart:off' then form1.CheckBox_autostart.Checked:=false;
   if ts.Strings[16]='debug:off' then form1.CheckBox_DebugLog.Checked:=false;
   if ts.Strings[17]='hidecmd:off' then form1.CheckBox_verstecke_cmd.Checked:=false;

...

  if form1.CheckBox_tray.Checked=false then ts.Add('tray:off') else ts.Add('tray:on');
  if form1.CheckBox_autostart.Checked=false then ts.Add('autostart:off') else ts.Add('autostart:on');
  if form1.CheckBox_DebugLog.Checked=false then ts.Add('debug:off') else ts.Add('debug:on');
  if form1.CheckBox_verstecke_cmd.Checked=false then ts.Add('hidecmd:off') else ts.Add('hidecmd:on');

...

 if form1.idftp1.DirectoryListing[i].FileName='.'=false then
 if form1.idftp1.DirectoryListing[i].FileName='..'=false then begin

Lieber in dieser Form:

Delphi-Quellcode:

if not tdirectory.exists(programmpfad + 'LS') then tdirectory.CreateDirectory(programmpfad + 'LS');
if not tdirectory.exists(programmpfad + 'RE') then tdirectory.CreateDirectory(programmpfad + 'RE');
if not tdirectory.exists(programmpfad + 'ET1') then tdirectory.CreateDirectory(programmpfad + 'ET1');
if not tdirectory.exists(programmpfad + 'ET2') then tdirectory.CreateDirectory(programmpfad + 'ET2');

if form1.CheckBox_autostart.checked then form1.Button_start_action.Click;

...

form1.CheckBox_tray.Checked := ts.Strings[14] = 'tray:on';
form1.CheckBox_autostart.Checked := ts.Strings[15] = 'autostart:on';
form1.CheckBox_DebugLog.Checked := ts.Strings[16] = 'debug:on';
form1.CheckBox_verstecke_cmd.Checked := ts.Strings[17] = 'hidecmd:on';

...

  ts.Add(IfThen(form1.CheckBox_tray.Checked,'tray:on','tray:off'));
  ts.Add(IfThen(form1.CheckBox_autostart.Checked,'autostart:on','autostart:off'));
  ts.Add(IfThen(form1.CheckBox_DebugLog.Checked,'debug:on','debug:off'));
  ts.Add(IfThen(form1.CheckBox_verstecke_cmd.Checked,'hidecmd:on','hidecmd:off'));

...

 if (form1.idftp1.DirectoryListing[i].FileName <> '.')
 and (form1.idftp1.DirectoryListing[i].FileName <> '..') then begin

Und nein: Da ist jetzt kein Muss, sondern nur als Idee für die eventuelle, zukünftige Beachtung gedacht.
Und vermutlich haben andere dazu auch andere Ansichten.

[Delphi.Narium]

Beispiel 3:

Delphi-Quellcode:

var
  ts : tstringlist;
begin
  ts := tstringlist.create;
  try
    try
      mach das 1
      mach das 2
      mach das 3
    except
      on e : Exception do begin
        MessageDlg(e.Message,mtError,[mbOk],0);
        // oder eine beliebige, aber garantiert funktionierende Variante der Fehlerprotokollierung.
        // aber nie ein  -- wie venice2 schon sagt:
        //
        // Sorry eine leere Fehlerbehandlung ist ein Nonsens.
        // 
        // bei einem Fehler wird nichts gemacht. fährt aber nach except weiter? <-- Wenn das nicht klar ist, ist das zu verifizieren.
        //
        // Es ist immer sinnvoll zu wissen, ob an einer Stelle Fehler auftreten oder nicht. 
        // Insbesondere dann, wenn nach nichtlokalisierbaren Fehlern gesucht wird.
        // Du hast schon ein
        Addline_Debug(Format('Nachvollziehbare Angabe zum Fehlerort: %s',[e.Message]));
        // Dann nutze es auch ;-) 
      end;
    end;
  finally
    ts.free;
  end;
end;

Bezüglich des korrekten Hinweises von TomF zur Position des ts:=tstringlist.create; Kompilerwarnungen sind zu beachten und die Ursachen der Warnungen zu beheben, die kommen nicht "zum Spass". Es sind oft Kleinigkeiten, aber die summieren sich im Laufe von Stunden und momentan blickt niemand so recht, wo genau die Ursache des Problemes liegen könnte, mit dem Du Dich gerade rumschlagen musst. In so 'nem Fall kann Pingeligkeit durchaus zielführend sein

[venice2]

Zitat:

wo genau die Ursache des Problemes liegen könnte, mit dem Du Dich gerade rumschlagen musst

Wenn man alles gelesen hat sollte einem Aufgefallen sein das sich die Handles summieren.
Wie es mit dem Speicher aussieht darüber gab es noch keine Information.

Aber gut zusammen geschustert.

[Delphi.Narium]

Zitat von venice2:

Zitat:

wo genau die Ursache des Problemes liegen könnte, mit dem Du Dich gerade rumschlagen musst

Wenn man alles gelesen hat sollte einem Aufgefallen sein das sich die Handles summieren.
Wie es mit dem Speicher aussieht darüber gab es noch keine Information.

Aber gut zusammen geschustert.

Wir wissen, dass sich die Handles aufsummieren!

Aber warum sie sich aufsummieren ist (zumindest mir) bisher nicht klar geworden.

Meiner Meinung nach kennen wir eine Folge eines Fehlers (oder möglicherweise mehrerer Fehler?), aber noch nicht die Ursache(n)