Hallo Leute,
ich habe in einem älteren Programm einen (für mich) seltsamen Fehler. Nach ca. einem halben Tag Laufzeit kommt es zu einem Thread-Fehler. Der Callstack führt mich zu einem TThread.Create. Es handelt sich bei diesem Thread, der in regelmäßigen Abständen eine Referenzliste aus einer Datenbank abruft um diese aktuell zu halten. Von diesen Threads gibt es mehrere, weil teilweise unterschiedliche Intervalle notwendig sind. Der Thread wird bis zum Mittag einige hundert mal aufgerufen und läuft fehlerfrei durch.
Vor dem Start des Threads wird geprüft ob er aus irgendeinem Grund noch läuft und wird beendet.
Beendet wird er so:

zusammenfalten · markieren

Delphi-Quellcode:

proceudre Tfrm_main.KillThreadUrlaubsGrund;
var
  ThreadHandle: THandle;
begin
  if ThLoadUrlaubsGrund<>nil then
  begin
    ThreadHandle:=ThLoadUrlaubsGrund.Handle;
    ThLoadUrlaubsGrund.OnFinished:=nil;
    ThLoadUrlaubsGrund.OnNewUrlaubsgrundList:=nil;
    ThLoadUrlaubsGrund.Terminate;
    WaitForSingleObject(ThreadHandle, 500);
    ThLoadUrlaubsGrund:=nil;
  end;
end;

Gestarte wird er so:

markieren

Delphi-Quellcode:

  
  KillThreadUrlaubsGrund;
  ThLoadUrlaubsGrund:=TThreadLoadUrlaubsgrundList.Create(True, dm1.Con);
  HandleUrlaubsgrundListThread:=ThLoadUrlaubsGrund.Handle;
  ThLoadUrlaubsGrund.OnFinished:=OnFinishUrlaubsGrundThread;
  ThLoadUrlaubsGrund.OnNewUrlaubsgrundList:=OnUpdateUrlaubsGrundList;
  WritePrivateLog('Start Thread UrlaubsGrund ('+IntToStr(HandleUrlaubsgrundListThread)+')');
  ThLoadUrlaubsGrund.Resume;

Der Fehler tritt dann im Create des TThreadLoadUrlabusgrundList auf:

zusammenfalten · markieren

Delphi-Quellcode:

constructor TThreadLoadUrlaubsgrundList.Create(Suspended: Boolean;
  Con: TZConnection);
begin
  inherited Create(Suspended); //<--------- Hier zeigt Callstack den Fehler Thread-Fehler: (6)
  FDBHost:=Con.HostName;
  FDBPort:=Con.Port;
  FDBUser:=Con.User;
  FDBPass:=Con.Password;
  FDBDatabase:=Con.Database;
  FDBProtocol:=Con.Protocol;
  self.FreeOnTerminate:=True;
end;

Beende ich den Thread falsch? Der Thread läuft mit FreeOnTerminate=True.
Als letzte Zeile im Execute des Thread rufe ich noch einen Event auf, der im Aufrufthread die Variable des Thread auf nil setzt. Sollte also der Thread, aus welchem Grund auch immer, länger brauchen als der Aufrufintervall definiert ist, soll er über die Methode KillThreadUrlaubsGrund gekillt werden.

Vielleicht steh ich ja auf dem Schlauch, und mache irgendwas grundlegend falsch.

So direkt sehe ich da keine Auffälligkeit (außer der Verwendung von Resume anstelle von Start), aber das ganze Design ist IMO suboptimal und fehleranfällig, besonders wenn die verwendete DB-Konnektion nicht multithread-tauglich ist.

Anstatt jedesmal einen neuen Thread zu erzeugen würde ich einmal zu Beginn einen Thread erzeugen der dann in einer Schleife in seiner Execute Methode auf einen Event (TSimpleEvent z. B.) wartet, mit einem Timeout, der dem gewünschten Aktivitätsintervall entspricht. Wenn der Event "aufwacht" prüft der Kode zuerst, ob Terminated True ist; wenn ja verläßt er die Schleife und der Thread beendet sich. Wenn Terminated False ist prüft der Kode den Rückgabewert der WaitFor-Methode des Events; das sagt ihm, wieso der Event ausgelöst hat. Wenn das der Timeout war setzt der Kode den Event wieder auf "not signalled" und ruft dann die Methode auf, die die Arbeit mit der Datenbank erledigt. Wenn es nicht der Timeout war sollte die Arbeitsschleife ebenfalls beendet werden. Dadurch kann man den Thread kontrolliert von außen beenden, in dem man den Event auslöst.

Es gibt eine globale Variable mit der Referenz auf die TThread-Instanz,
aber gleichzeitig wird durch FreeOnTerminate irgendwann die Instanz gelöscht und diese Variable wird ungültig.

Auf solche Variablen darf man bei Verwendung von FreeOnTerminate eigentlich nie wieder drauf zugreifen (besser es gibt erst garnicht solche Variablen),
es sei denn man gestaltet diese Zugriffe thread-safe (CriticalSection), also um das Auslesen, als auch um das :=nil, welches am Ende des Threads von Diesem gemacht werden muß.

Auch das extern gespeicherte Thread-Handle ist nach dem Ende des Threads ungültig.
Hier könnte man sich via DuplicateHandle ein eigenes Handle besorgen und damit weiterarbeiten.
Kurz nach Erstellen/Start des Threads (wenn dieser "garantiert" länger läuft), oder besser innerhalb des Threads dupplizieren, also so lange das Thread.Handle garantiert gültig ist.