Als Datenstruktur käme evtl. auch ein Ringpuffer in Betracht.

Die Frage ist auch, welche Stelle genau den Stacküberlauf auslöst.
Mittels MadExcept oder Eurekalog könnte man im Absturzfall einen
Stacktrace bekommen, der einem das evtl. zeigt.

Eine kostenlose, aber nicht ganz so schöne Stacktrace Variante
findet man in der JEDI JCL.

Evtl. könnte man auch mal auf ein neueres Delphi wechseln, da hat
sich auch beim Multithreading usw. einiges getan und wenn man solche
Drittanbieter Bibliotheken braucht, tut man sich mit neueren Versionen
auch leichter, da die Unterstützung für so alte Versionen inzwischen
doch (verständlicherweise!) schwindet...

Grüße
TurboMagic

... prima, auch am Wochenende gibt es Antworten.

Bei dem Buffer handelt es sich nur um zwei abwechselnd beschriebene statische Datenfelder. Das ist ausreichend, da es sich um langsame Vorgänge handelt. (alle 10 Minuten eine Messung speichern)

Ich habe jetzt mal die ganzen Threads usw. durch eine Simulation der
Daten ersetzt und bekomme trotzdem einen Gehler. Diesmal ist eine access violation, der stack overflow ist dann wohl ein Folgefehler. Damit hatte
ich nun garnicht gerechnet. Der Fehler tritt erst nach ca. 20 Minuten Laufzeit auf.

Für die Anzeige habe ich mir einen frame gebaut (nichts aufregendes nur ein paar edits und labels), den erzeuge ich beim Start 16 mal als Element
eines Feldes vom type frame. Da werden dann die Daten angezeigt. Ich muss dort mal weiter suchen.

Also threads und Hardware sind wohl erstmal nicht die Schuldigen.
Trotzdem: DANKE

Stack overflows sind normalerweise Folge eines rekursiven Aufrufs einer Routine, eventuell auch indirekt (A -> B -> C -> A ...). Ohne den Kode deiner Execute-Methoden zu sehen (und wie dein Timer mit den Threads interagiert) ist eine weitere Diagnose nicht möglich. Aber ich habe da eher eine Programmierfehler im Verdacht, da der Fehler ja an der Zahl der Aufrufe zu hängen scheint, nicht an der Frequenz.

Neben dem, was Peter Below schrieb, gibt es noch den Fall, dass z.B. durch Application.ProcessMessages ein neuer Timer-Event ausgelöst wird, während der alte noch läuft.

markieren

Delphi-Quellcode:

procedure TMyForm.MyTimerTimer(Sender);
begin
  // Code
  Application.ProcessMessages;
  // mehr Code
  Application.ProcessMessages;
  // noch mehr Code
end;

Jedes Application.ProcessMessages kann dazu führen, dass der Timer neu ausgelöst wird, wenn der Code länger läuft als das Timer-Intervall.

Dabei läuft dann auch der Stack ganz langsam voll. Je kürzer das Intervall, desto schneller.

Hallo zusammen,
nochmals danke!
Das Proplem ist gelöst. Der Stackoverflow hatte mich auf eine falsche Spur gesetzt.
Letzlich war es ein Timer-Event in Zusammenhang mit Application.ProcessMessages. Im Hintergrund liefen unsichtbar 16 kleine Grafiken mit, die erst auf Anforderung des Anwenders angezeigt werden sollen. Die hatte ich übersehen. Je mehr Daten die Grafiken enthielten, desto länger dauerte ihr refresh. Irgendwann war das dann zu lang. Ich denke der Stackoverflow war dann nur ein Folgefehler. Bei der Fehlersuche konnte och die Abbrüche auch ohne die Threads nur mit Dummy-Daten erzeugen. Fazit: wieder was gelernt und immer die komplette Verarbeitungskette anschauen, auch wenn sie für den Anwender unsichtbar ist.