Win64 VCL Applikation Delphi 11.3 - not respondig

[taveuni]

Hallo Gemeinde,
Ich habe ein sehr grosses Projekt von XE2 auf Delphi 11.3 migriert. Wobei es eher eine Neuentwicklung ist welche auf den Erfahrungen der alten Applikation abstützt. Es handelt sich um einen Client welcher mit einer Fremd API H264 Videostreams mit bis zu 50fps anzeigen kann. Die alte XE2 Applikation benutzte dazu ein ActiveX des Herstellers. Dieses ist End of Life. Neu wird eine 64bit C DLL API benutzt. Die Entwicklung dauerte ca. ein halbes Jahr. Nun sind wir im Release Candidate Test beim Kunden. Weil wir verfügen nur über ca. 20 Kameras hier. Beim Kunden sind es einige tausend.

Der Client wird auch vom Server fremdbeschaltet (Videowall Betrieb). Hier kann z.B. in einem Rutsch ein Aufschaltbefehl für 36 Kameras (mit der entsprechenden Splitschaltung) kommmen. Ein paar Sekunden später ein 4-er Split mit anderen Kameras usw. Meistens funktioniert das alles sehr geschmeidig. Manchmal aber eben nicht. Es gibt zwei Phänomene.

1. Manchmal bleibt die Applikation mitten in einer Aufschaltung stehen. Es sollte z.B. ein 9-er Split aufgeschaltet werden. Die ersten 5 Kameras streamen bereits live. Bei den letzten 4 ist noch der Verbindungsaufbauscreen zu sehen. Die Applikation kann noch an der Kopfzeile gepackt und leicht bewegt werden. Die Streams streamen mit den vollen Auflösung. Wenn in die Applikation geklickt wird erscheint "not responding". Alle Callbacks von der API kommmen in Threads. Diese sind alle abgesichert und werden mit der VCL synchronisiert. Mein erster Verdacht war das TThread.Synchronize. Dann habe ich alles auf PostMessage umgestellt. Mit dem gleichen Resultat. In die API muss ein Handle der (Panel-) Komponenten mitgegeben werden. Auf diese zeichnet dann die API. Ich habe 100-e Seiten gelesen und auch verstanden dass z.B. TWinControl.Handle Getter nicht Threadsafe sind. Deshalb habe ich auch die synchronsiert bzw. in Variablen gespeichert. Ebenso ein krass intensives Logging wurde eingeführt. Das sieht man jeweils meisten als letzten Logeintrag ein PostMessage an das Hauptformular welches dort nicht mehr ankommt. Testweise habe ich auch einen Timer mit einem 5Sekunden Interval Log platziert. Auch dieser hört dann in dem Moment auf. Es sieht also so aus dass das Messaging den Betrieb komplett eingestellt hat. Die CPU Auslastung ist auf 2% in diesem Zustand. Das rendering der Streams passiert zu 100% auf der GPU.

2. Die Walls welche durchlaufen sind manchmal nach einer Woche weg. Im Windows Eventlog ist das eine Exception in der NTDLL.DLL zu finden. Ich habe schon mit Eureka Log kompiliert. EurekaLog kriegt den Absturz nicht mal mit.

Tja. Guter Rat ist teuer. Hat jemand eine Idee oder schon mal was ähnliches erlebt? Das Problem ist auch: Es könnte an der API liegen? Aber wie kann ich das belegen? Wie kann ich die Ursache dieser Symptome finden? Einmal konnte ich mich per RemoteDebugger auf einen stehenden Client verbinden. Im Hauptthread an den Stellen der Messages ist (logischerweise) aber nichts gekommen. Im Processexplorer sehe ich haufenweise Threads vor allem der API DLLs. In meinem Programm sehe ich anhand der ID nur noch einige und in die bin ich mit Breakpoints rein. Der Hauptthread rödelt mit 0.1% CPU dahin. Da war nichts. Was ist da los?

Vielen Dank für jeden Input
Gruss Werner

[shebang]

Zitat:

Zitat von taveuni (Beitrag 1532190)

Das sieht man jeweils meisten als letzten Logeintrag ein PostMessage an das Hauptformular welches dort nicht mehr ankommt.

Das Logging ist komplett vom Hauptthread entkoppelt, d.h. es läuft weiter wenn du den Hauptthread absichtlich schlafen legst?

[taveuni]

Grundsätzlich ja. Ich setzt Loggerpro ein. Events from Server werden weiterhin geloggt. Kommen aber im Hauptthread nicht mehr an. Obwohl dieser Null CPU beansprucht. Das verwirrt mich total.

[Uwe Raabe]

Zitat:

Zitat von taveuni (Beitrag 1532190)

dass z.B. TWinControl.Handle Getter nicht Threadsafe sind. Deshalb habe ich auch die synchronsiert bzw. in Variablen gespeichert.

Das wird vermutlich nicht reichen. Der Zugriff auf VCL-Controls aus einem Thread heraus ist eben nicht thread-safe. Selbst wenn man ein solches Handle synchronisiert erhält, bedeutet das nicht, dass es beim nächsten Mal auch noch gültig ist. VCL-Controls erzeugen immer mal wieder ihr Handle neu.

Solange die Controls permanent vorhanden sind, kann man Referenzen auf diese verwenden um die entsprechenden Aktionen synchronisiert auszuführen. Innerhalb dieser Aktion kann man auch das Handle verwenden, solange man sicher ist dass es während der Aktion nicht durch irgendwas neu erzeugt wird. Im Zweifelsfall an jeder Stelle das Handle Property verwenden und nicht irgendwo zwischenspeichern.

[taveuni]

Zitat:

Zitat von Uwe Raabe (Beitrag 1532195)

Das wird vermutlich nicht reichen. Der Zugriff auf VCL-Controls aus einem Thread heraus ist eben nicht thread-safe. Selbst wenn man ein solches Handle synchronisiert erhält, bedeutet das nicht, dass es beim nächsten Mal auch noch gültig ist. VCL-Controls erzeugen immer mal wieder ihr Handle neu.

Solange die Controls permanent vorhanden sind, kann man Referenzen auf diese verwenden um die entsprechenden Aktionen synchronisiert auszuführen. Innerhalb dieser Aktion kann man auch das Handle verwenden, solange man sicher ist dass es während der Aktion nicht durch irgendwas neu erzeugt wird. Im Zweifelsfall an jeder Stelle das Handle Property verwenden und nicht irgendwo zwischenspeichern.

Ich bin mir nicht sicher ob ich Dich richtig verstehen. Die GUI besteht aus einzelnen "Playern" welche diese Panels, die Verbindungsscreens usw. kapseln. Diese werden auch dynamisch freigegeben und erzeugt. Wenn z. B. ein Player via API versucht eine Verbindung zu erzeugen welche nicht vorhanden ist und vor dem Timeout für diesen Player eine neue Aufschaltung kommt wird der bestehende freigegeben und ein neuer erzeugt.
Beim ersten synchronisierten Aufruf dieses Players wird dann das Panel.Handle sicher ermittelt und einer Klassenvariable gespeichert. Folgend wird immer diese Variable mit einem Getter der Klasse mit TCriticalSection abgesichert geholt und der API übergeben. Ist das so gemeint von Dir?

[taveuni]

Zitat:

Zitat von Uwe Raabe (Beitrag 1532195)

Im Zweifelsfall an jeder Stelle das Handle Property verwenden und nicht irgendwo zwischenspeichern.

Was aber wenn ich das Handle benötige um mit PostMessage aus einem Thread heraus zu notifizieren? Vermulich ist das dann sowieso der falsche Ansatz und ich sollte für dies wieder zu Events zurückkehren. Und dies mit TThread.Synchronize tun. Dann bin ich diesbezüglich aber wieder am Anfang.

[Kas Ob.]

@taveuni , hi

Sorry for "My bad is English" and the translation, so i might missed many stuff.

But i did few projects with security cameras and recording/handling images software, and want to points few things that can be problem for you to face:

1) The most important thing is to have small code to test the limit of decoding, this code should be portable and included within the software, i mean yes you have hardware (GPU) decoding but there is limit of how many streams can be decoded concurrently, GPU tend to throttle instantly.
2) Crucial thing to do is to not allow or implement any sort of inter-threads communication, i mean 0 interaction between threads them selves or with the main threads, this make no sense at first but will i will explain it further down.
3) the drawing form the main thread should not perform more than fixed frame per second, and definitely should not wait on the background decoding threads, and will not have (or wait for) any notification from them.
4) logging should be lock free.

Now to some details :
GPU decoding can be overwhelmed easily and will stop/slow for each and every stream, so should be throttled, hence the test and benchmark, also after feeding the stream and when you want to decode to different one, make sure to flush the stop decoding for the ones that is not needed, if the application is to save the encoded streams then let them continue to just save only.
The decoding threads will have the decoded images in a ring buffer, lock free would be perfect but any will do, and will not perform any notify for that matter, just drop the image in bucket or list or whatever....
Drawing from the main thread should be happen with a timer, simple as that, remove the images from the buffers then draw then recycle, try to recycle (cache) these Bitmaps, again with lock free list.
That timer must not be more frequent than the Hz of the monitor and the FPS from these streams.
Mainthread will draw/render all the images, if there were new images or not, it will just consume what in the filled buffer from each decoding threads.

Your decoding DLL might provide two method of decoding synchronous and/or asynchronous, use the synchronous (blocking) one.

As a rule of thumb stay away from sending/posting messages, the interthread communication should be limited to go and stop, and may be , i say be a counter for decoded images, and that is it.

After building that you can go fancy and add features, like watermarks special editing, motion detection ...

Hope that helps.

[Uwe Raabe]

Zitat:

Zitat von taveuni (Beitrag 1532202)

Was aber wenn ich das Handle benötige um mit PostMessage aus einem Thread heraus zu notifizieren?

Was aber, wenn das Handle durch ein RecreateWnd neu erzeugt wird? Das kann auch bei einem Control in der Parentfolge des Panels sein, was dann auch das Handle des Panels unbrauchbar macht.

Das Problem besteht übrigens unabhängig von Threads.

[himitsu]

Passiert auch, wenn man StayOnTop ändert
oder wenn ein Fenster minimiert ist und aus Platzspargründen vorübergehend aus dem Speicher fliegt.

Für sowas sollte man sich in eines der entsprechenden Methoden einhängen

Delphi-Quellcode:

    procedure CreateWindowHandle(const Params: TCreateParams); virtual;
    procedure CreateWnd; virtual;

    procedure DestroyHandle; virtual;
    procedure DestroyWindowHandle; virtual;
    procedure DestroyWnd; virtual;

bzw. WM_CREATE, WM_DESTORY, CM_RECREATEWND usw.


z.B. bloß im Constructor eine Funktion am Handle (HWND) zu aktivieren und sich dann zu wundern, wenn sie zur Laufzeit irgendwann mal weg ist ... schon bissl unpraktisch.

[taveuni]

Ich bin jetzt 4 Tage nicht im Büro. Werde mich am Dienstag wieder damit beschäftigen. Allgemein: was kann den Hauptthread lahmlegen ohne dass dieser beschäftigt ist?

[himitsu]

ein Deadlock ... Sleep, WaitFor oder I/O, wo der Treiber auf was wartet, usw.

Wenn es lang genug hängt, im Debugger auf Pause und schauen wo der Thread grade hängt (Stack).

[taveuni]

Zitat:

Zitat von himitsu (Beitrag 1532233)

ein Deadlock ... Sleep, WaitFor oder I/O, wo der Treiber auf was wartet, usw.

Wenn es lang genug hängt, im Debugger auf Pause und schauen wo der Thread grade hängt (Stack).

Da fehlt mir leider das Verständnis. Als ich mich mit dem remote debugger eingehängt hatte war ja irgendwie pausieren nach Verbindung angehakt. Da würde ich dann etwas sehen?
Ich komme gerne darauf zurück.

[hoika]

Hallo,
funktioniert denn die alte Installation/ Exe noch.

Nicht das sich in der Zwischenzeit irgendwas anderes geändert hat ...

[himitsu]

Diese Option sagt nur, dass der Debugger kurz nach dem Start der Anwendung schon anhalten soll, man also das Starten der Anwendung debuggen kann.

Du willst doch erstmal etwas laufen lassen, bis das Fenster geladen ist, also erst ab da wo die GUI hängt.
Wie bei Kassette, CD, DVD usw.
Es gibt den Start-Knopf ⏵ (mit und ohne Käfer), einen Knopf zum Beenden ⏹ und ⏸ :zwinker:
ohne Käfer = ohne Debugger starten

Und dann noch Tasten (F7/F8) um langsam weiterzugehn (Schritt für Schritt oder ein gaaaanz großer Schritt, bis es wieder zurück/heim kommt)

[jaenicke]

Ich habe für threadgesteuerte Fenster ohne die VCL gearbeitet. Dann kann der Thread oder mehrere Threads die Kontrolle über das Fenster haben und dort alles machen.

Für den Zweck hatte ich eine kleine Bibliothek angefangen, aber mangels Interesse nicht mehr viel daran gemacht bzw. meine lokalen Änderungen (noch) nicht veröffentlicht:
https://github.com/jaenicke/MTCL
Es könnte aber reichen, damit du für jeden Thread vor deinem eigentlichen Fenster testweise ein eigenes Non-VCL Fenster positionieren kannst und der Thread kann auf dessen Handle dann alles machen. So könntest du testen, ob es ohne VCL funktioniert. Wenn es dann nicht mehr knallt, kannst du immer noch schauen, wie du weitermachen kannst.

[taveuni]

Zitat:

Zitat von jaenicke (Beitrag 1532240)

Ich habe für threadgesteuerte Fenster ohne die VCL gearbeitet. Dann kann der Thread oder mehrere Threads die Kontrolle über das Fenster haben und dort alles machen.

Für den Zweck hatte ich eine kleine Bibliothek angefangen, aber mangels Interesse nicht mehr viel daran gemacht bzw. meine lokalen Änderungen (noch) nicht veröffentlicht:
https://github.com/jaenicke/MTCL
Es könnte aber reichen, damit du für jeden Thread vor deinem eigentlichen Fenster testweise ein eigenes Non-VCL Fenster positionieren kannst und der Thread kann auf dessen Handle dann alles machen. So könntest du testen, ob es ohne VCL funktioniert. Wenn es dann nicht mehr knallt, kannst du immer noch schauen, wie du weitermachen kannst.

Vielen Dank
Den Weg werde ich mal gehen.