Mandelbug auf die Schliche kommen

[Medium]

@Zacherl: Die Socket-Kommunikation scheint nach aktuellen Erkenntnissen als Übeltäter auszuschließen zu sein. Es ist auch nur ein einfacher TClientSocket ohne Aufbauten und Schickschnack. Den würde ich vorerst als unschuldig und abgehakt ansehen glaube ich.

@Sir Rufo: Das war eine Befürchtung die ich hatte, wobei die CS-Struktur in etwa so aussieht:

Code:

procedure UpdateVCLControls;
begin
  EnterUpdateCS;
  try
    while UpdateList.Count > 0 do
    begin
      try
        LogSomething;
        DoSometingWithUpdateListItem(0);
        LogSomething;
        DoSometingWithUpdateListItem(0);
        ...
      finally
        UpdateList.Delete(0);
      end;
    end;
  finally
    LeaveUpdateCS;
  end;
end;

procedure LogSomething;
begin
  EnterLogCS;
  try
    Log;
  finally
    LeaveLogCS;
  end;
end;

Das Anfügen an die UpdateList würde daher imho durch die CS des Loggings eigentlich nicht weiter beeinflusst werden, da diese immer nur betreten und verlassen wird, während die UpdateList ohnehin schon gelockt ist. Dennoch: Lasse ich die LogSomething-Aufrufe weg, habe ich wieder meine sporadischen Hänger.

Die UpdateList ist eine TObjectList (OwnsObjects=true), die Items dieser Klasse trägt:

Delphi-Quellcode:

  TVCLUpdateData = class
  public
    Instance: TObject;
    ClassType: TClass;
    PropName: String;
    Value: Variant;
    constructor Create(aInstance: TObject; aType: TClass; aPropName: String; aValue: Variant);
  end;

Der UpdateThread füllt diese Liste anhand neuer Daten aus der Datenbank, wobei die Komponenten anhand ihres Names per FindComponent() ausfindig gemacht wurden (und auch die gesamte Programmdauer existieren). Es sind geprüfterweise immer gültige Referenzen.
Die Update-Loop (die Prozedur oben im Pseudocode) macht letztlich innerhalb der while-Schleife nur dieses: SetPropValue((item.Instance as item.ClassType), item.PropName, item.Value); (Mit zuvoriger Prüfung, ob item.Value ungleich NULL ist und die Instanz wirklich vom Typ "ClassType" ist.) "item" wird zuvor UpdateList[0] as TVCLUpdateData zugewiesen.
Die Update-Loop wird per PostMessage() vom UpdateThread angestoßen, nachdem dieser alle im aktuellen Zyklus anstehenden Updates gesammelt hat.

@Morphie: Leider bleibt der Debugger nicht an einer sinnvollen Stelle stehen. Da das Problem offenbar keine Exception auslöst, und ich nicht 6h durchsteppen kann bis der Fehler freundlicherweise mal auftritt (und es dann vermutlich auch nicht tut), hatte ich das aufgegeben

[Sir Rufo]

Wenn du das Update per PostMessage anstösst, warum dann eine CS?
Dann läuft das doch auch im MainThread-Kontext und eine CS ist dann überflüssig.

Du solltest abprüfen, ob beim Aufruf der Update-Methode auch MainThreadID = GetCurrentThreadID ist (sollte ja so sein).
Die VCL reagiert auch dann komisch, wenn man trotz CS aus einem anderen Thread darauf zugreift

[Namenloser]

Wo gerade schon PostMessage in einem anderen Zusammenhang erwähnt wurde: Bau doch deinen Logger so um, dass er mit Messages arbeitet (Also einen neuen Logger-Thread mit eigener Message-Loop machen, und dann immer mit PostThreadMessage die Log-Einträge an ihn schicken). Dann sollte das Logging IMO auf den Programmablauf keinen Einfluss mehr haben.

Zum Remote-Debugging: Man vergisst es manchmal, weil man damit meistens nur in den Untiefen des WinAPI-Assemblercodes landet, aber es gibt beim Debugger auch noch den Pause-Button . Ich hab damit z.B. gestern rausgefunden, dass mein Multi-Thread-Programm sich in WaitForSingleObjectEx aufgehängt hatte. Vielleicht kannst du den Fehler damit doch eingrenzen.

[Medium]

Zitat von Sir Rufo:

Wenn du das Update per PostMessage anstösst, warum dann eine CS?
Dann läuft das doch auch im MainThread-Kontext und eine CS ist dann überflüssig.

Die Liste, die in der Update-Prozedur abgearbeitet wird, wird in einem anderen Thread mit neuen Items versorgt. Diese wird dort abgesichert, nicht die VCL Controls.

Remote-Debugging hat sich mittlerweile erledigt, da ich das Gerät vorhin wieder beim Kunden hin gehängt habe. Ich durfte das Teil leider nur über das Wochenende haben, die Mittagsschicht heute brauchte es wieder
Die Idee das Logging so zu entkoppeln ist aber interessant. Das könnte ich da mal bei Gelegenheit rein bauen! Cool.

[nahpets]

Hallo,

weiß nicht, ob ich hier hilfreich sein kann.

Habe ein Programm, das aber ein ähnliches Verhalten an den Tag legt.

Es dient dazu per TIDHTTP diverse Listen von Dateien von unterschiedlichen Server abzuholen und als Dateien lokal zu speichern bzw. abhängig vom Inhalt der Dateien Einträge in einer Datenbank vorzunehmen.

Es laufen immer mehrere Threads, die jeweils eine eigenen HTTP-Verbindung aufmachen.

Ab und an klappt da was nicht und ein Thread bleibt stehen.

Habe dann ein Logging eingebaut, das mir alle Fehler protokolliert. Das klappt auch soweit. Wenn ein Thread stehen bleibt, muss aber kein Fehler aufgetreten sein. Was mir aber in den Logdateien aufgefallen ist, ist folgendes: Bevor ein Thread stehen bleibt, ist in diesem oder einem anderen Thread, mit einer Verbindung zu dem gleichen Server, ein Fehler aufgetreten (meist Fehler 500 - interner Serverfehler - auf Serverseite). D. h.: Nachdem ein Fehler auftrat, scheint eine neue Verbindung zu dem entsprechenden Server (häufig, aber nicht immer) zu scheitern, aber nicht so, dass ein abfangbarer Fehler auftritt, sondern die Verbindung per TIDHTTP scheint in einen nicht definierten Zustand zu treten. Sie kommt nicht zurück, es ist auch keine Tätigkeit im Netz von dieser Verbindung zu erkennen, die Verbindung bleibt aber (laut Firewall) bestehen, ein Timeout tritt auch nach Stunden nicht auf. Dieser Zustand läßt sich nur durch das Beenden des Programmes beheben.

Eine Lösung habe ich nicht, bei meinem Programm gehe ich momentan her und beende die weitere Verarbeitung, sobald ich eine Fehlermeldung im Logging feststellen kann. Es wird dann eine Meldung ausgegeben. Wird die Verarbeitung dann (ohne Programmneustart) neu gestartet, kann es sein, dass sie über Stunden problemlos weiterläuft (bis irgendwann der nächste "Hänger" auftritt).

Könnte es sein, dass bei dem hier beschriebenen Problem ein ähnlicher "Zustand" eintritt?