Programm stürzt nach mehren Stunden Laufzeit ab.

[jaenicke]

Ein Beispiel:
Du erstellst in PrinServer_action eine TStringList, hast aber keinen try..finally Block zur Freigabe drum. Tritt also ein Fehler auf oder springst du mit abort (ein paar Zeilen nach dem begin) raus, wird diese nicht wieder freigegeben.

Im Laufe vom Stunden summiert sich dann dieser nicht freigegebene Speicher und am Ende ist der voll und es geht gar nichts mehr. (Es kann auch sein, dass da noch mehr nicht freigegeben wird, ich habe nicht genau geschaut.) Und dann kann Indy auch nicht mehr richtig mit dem Server sprechen und es kann zu ganz komischen Fehlern kommen. Achte mal auf den Speicherverbrauch im Taskmanager, wenn der Fehler auftritt.

Davon unabhängig brauchst du das abort (sprich die stille Exception) in deinem Quelltext definitiv nicht. Zur Steuerung des Programm- und Schleifenablaufs gibt es mit Exit, Break, Continue usw. saubere Möglichkeiten. Das in Kombination mit Ressourcenschutzblöcken (try..finally) sollte Besserung bringen.

[Delphi.Narium]

Bei meinen HTTP-Klamotten kenn' ich das Problem in ähnlicher Form. Hier hat folgendes geholfen:

Delphi-Quellcode:

  // Grundsätzlich hinter jedes
  http.Disconnect(True);
  // noch ein.
  http.IOHandler.InputBuffer.Clear;

Behebt nicht 100% dieser Fehlersituationen, aber statt (teils mehrfach) täglich tritt der Fehler kaum noch monatlich auf.

Könnte daher einen Versuch wert sein.

[gee21]

Also vielen Dank für eure Hilfe. (ich habe heute mal die Handles und weitere Infos im Taskmanager anzeigen lassen).

@TurboMagic: Früher habe ich nach jedem überprüfen die Verbindung getrennt und wieder neu aufgebaut. damit aber die Ausdrucke möglichst schnell aus dem Drucker kommen, musste ich +/- alle 5 Sekunden neu zum server verbinden und dann gleich wieder trennen. damit also die ausdrucke noch schneller aus dem Drucker kommen und damit ich den Server nicht mit meinen Verbindung unnötig belaste, wollte ich die Verbindung so lange offen lassen bis knapp vor dem Server/Idle TimeOut erreicht ist. (NOOP und NAT KeepAlive haben immer Probleme gemacht, vermultich aber durch mein Unwissen ).

@venice2: Ja du scheinst recht zu haben die Handles zählen aufwärts wie länger das Tool läuft.

@jaenicke: Vielen Dank für dein Beispiel. ich werde diese Sachen noch diese Woche anschauen und ausprobieren. Dann im Taskmanager vergleichen um zu sehen was wie hilft. Ich denke so sollte es dann klappen.

@Delphi.Narium: Danke auch dir vielmals. Ich werde dein Tipp ganz am Schluss (in 1-2 Wochen) auch noch abändern um dann zu erkennen/lernen was diese Änderung hilft/bewirkt


VIELEN DANK bin jedes mal froh über eure Hilfe

[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 ?

[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