Public Support

Hi Claudia,

das kann man leider nicht allgemein beantworten, da prinzipiell jeder Filter jederzeit Speicher am heap anlegen kann und es dann darauf ankommt ob er das behandelt. Wenn er das über new in einer Funktion eines Filters macht müssten wir aber zumindest die std:bad_alloc exception abfangen und in einen Fehler umwandeln. Da aber auch das Speicher benötigt, kann man das nicht garantieren. alloc_sample (output_sample_data<>) etc. sollten den Fehler aber korrekt fangen.

Ich würde aber vermuten, dass du letztendlich bei diesen Problemen mit einem Crash-Dump fast besser bedient bist.

Das Log wird im Crash Handler von ADTF nicht gesondert behandelt, heißt das was bisher geschrieben wurde ist drin, mehr nicht. Hier kann eben leider der Schreibpuffer dazu führen, dass da nicht wirklich alles auf der Platte gelandet ist.

Grüße,

Martin

Hi Martin,

ich habe das mittlerweile getestet. Der Filter sammelt alle seine Inputs in einem Vektor und der Arbeitsspeicher füllt sich dementsprechend. Nachdem der PC an seiner Grenze war, bekam ich bad_alloc exceptions und es wurde auch ein Crash Dump File gespeichert.
Ich weiß ehrlich gesagt nicht, wie ich dieses analysiere. Gibt es dafür spezielle Tools?
Aber ich vermute, dass die LOGs meines Filters nicht enthalten sind. Ein normaler User wird mit den Crash Dump Files sicher auch nichts anfangen können, daher war unsere Hoffnung, dass das LOG nach dem Absturz verfügbar ist.

Viele Grüße
Claudia

Hi Claudia,

Claudia Haßmann wrote:

ich habe das mittlerweile getestet. Der Filter sammelt alle seine Inputs in einem Vektor und der Arbeitsspeicher füllt sich dementsprechend. Nachdem der PC an seiner Grenze war, bekam ich bad_alloc exceptions und es wurde auch ein Crash Dump File gespeichert.
Ich weiß ehrlich gesagt nicht, wie ich dieses analysiere. Gibt es dafür spezielle Tools?

Einfach doppelklicken und Visual Studio öffnet sich. Kurzes googlen ergibt: https://docs.microsoft.com/en-us/visualstudio/debugger/using-dump-files?view=vs-2019

Alternativ kannst du den adtf_launcher auch direkt in Visual Studio starten und debuggen, dann springt er auch gleich an die Absturzstelle.

Aber ich vermute, dass die LOGs meines Filters nicht enthalten sind. Ein normaler User wird mit den Crash Dump Files sicher auch nichts anfangen können, daher war unsere Hoffnung, dass das LOG nach dem Absturz verfügbar ist.

Im Crash Dump sind die Logs nicht enthalten, das ist ja wirklich der Dump des Prozess Images.

Hast du den adtf_launcher mit "--log-file mein_log_file.txt" gestartet? Dort sollte schon so einiges landen. Ansonsten kannst Du ihn auch mit --console starten, dann siehst du beim debuggen im Konsolenfenster noch die letzen Ausgaben.

Grüße,

Martin

Hi Martin,

danke für die Hinweise.
Ich starte die Session immer aus dem Configuration-Editor heraus und gebe nichts Besonderes an. Die Console wird mir angezeigt und ich sehe auch meinen Output. Da ich aktuell weiß, dass ich den PC mit Memory Leaks überfordere, brauche ich auch nicht zu debuggen. Wir wollen aber sicherstellen, dass die künftigen Nutzer der Konfig auch auf solche Probleme hingewiesen werden. Mit dem Crash Dump File geht das nicht und die Console ist weg, wenn sich der PC aufgehangen hat. Heißt, wenn der Nutzer die Konfig über Nacht durchlaufen lässt, wird er am nächsten Tag einen abgestützten PC vorfinden, der ihm keinen Hinweis auf das Warum liefern.

Wenn man den lancher aber mit --log ... startet, dann wird das log file erzeugt und der Nutzer kann die Meldungen des Filters analysieren. Der Weg sollte für die künftigen Nutzer machbar sein.
Mein Problem ist damit gelöst und du kannst das Ticket schließen.

Vielen Dank
Claudia