Seite 1 von 1
Interpretation xppfatal
Verfasst: Mo, 27. Nov 2017 13:29
von Jan
Hallo,
welche Informationen würdet Ihr aus diesem log entnehmen:
FATAL ERROR LOG
Not recoverable Error!
SYS Thread-ID: 1556
Module: MOM
Error Codes: EH: 1006 Sub: 0(0) OS: 0 XPP: 15
Call Stack of Thread 1 (816):
MAIN(490)
Call Stack of GUI Thread (996):
Call Stack of Thread 3 (1556):
MYDBSKIP(1303)
KNX_SCHALTEN(754)
Call Stack of Thread 4 (1716):
File: P:\NG_WAWI\06 NG_Prog20\GIRASTATUS.EXE
TimeStamp: 20171124 19:14
End of FATAL ERROR LOG.
Main(490): Inkey(.01)
MYDBSKIP(1303): LOCAL bOldError := ErrorBlock( {|e| MyDbSeekErrorblock(e, @lExit)} )
KNX_SCHALTEN(754): knx_schalt->(myDbSkip())
Jan
Re: Interpretation xppfatal
Verfasst: Mo, 27. Nov 2017 13:44
von Tom
1. Es ist ein Fehler aufgetreten, der nicht durch das Fehlersystem behandelt werden kann (Non recoverable Error).
2. Der Fehler trat im Memory Objects Manager (MOM) auf, also in der Speicherverwaltung/im Memory-Management.
3. Der Fehler trat im Thread mit der ID 1556 auf, das ist Thread 3 Deiner App. Dort wurde er in Zeile 1303 und in der Funktion "MyDbSkip" ausgelöst.
Re: Interpretation xppfatal
Verfasst: Mo, 27. Nov 2017 14:35
von Jan
Hallo Tom,
danke für die Bestätigung. Ich hatte mir sowas ähnliches gedacht. aber bei den xppfatal bin ich doch eher vorsichtig, die sind immer noch etwas geheimnisvoll für mich.
Was für Gründe kann es geben für solche MOM-Fehler? Immerhin passiert ja im Code nichts seltsames.
Jan
Re: Interpretation xppfatal
Verfasst: Mo, 27. Nov 2017 14:44
von Tom
Hallo, Jan.
Was für Gründe kann es geben für solche MOM-Fehler?
Vermutlich viele, keine Ahnung - es ist ja nicht Dein Code, der den Fehler verursacht, sondern der MOM, also Alaska-Code. Du könntest Dich herantasten, indem Du - falls der Fehler nachstellbar ist - in Deiner Funktion herumschraubst, bis Du das so kleinteilig zerlegt hast, dass Du Alaska darüber informieren kannst (z.B. "Wenn ich einen 200 Zeichen langen String, der ausschließlich 'A's enthält, mit einem 'B' konkatiniere, tritt immer dieser Fehler auf. Hier ist Beispielcode."). Aber wahrscheinlich lässt sich das nicht machen. Ist der Fehler denn reproduzierbar? "Richtiger" Code sollte so etwas jedenfalls nicht erzeugen.
Re: Interpretation xppfatal
Verfasst: Mo, 27. Nov 2017 14:58
von brandelh
Ich meine mich zu erinnern, dass das häufiger mit Fremden DLLs auftritt, aber natürlich auch mit API etc. wenn z.B. die Parameter nicht sauber übergeben wurden (Alaska Code, andere API, Treiber etc.)
Meist liegt die eigentliche Fehlerursache auch an ganz anderer Stelle und es ist nur ein Zufall, dass es hier dann kracht.
Re: Interpretation xppfatal
Verfasst: Mo, 27. Nov 2017 15:08
von Jan
Hallo,
das ist ein Programm, das 24/7 durchläuft. Manchmal wochenlang ohne Probleme. Durch die betreffende Codesrequenz geht der ca. 40 - 80x/Minute. Also auch nicht nur mal so sporadisch. Und dann plötzlich - weg. Also nicht wirklich reproduzierbar.
Ich hab den Admin schon gebeten sich die einschlägigen logs anzusehen zum betreffenden Zeitpunkt (ich kann den durch das, was diese Funktion schriebt, relativ genau eingrenzen). Das hat aber keine probleme ergeben. Wir hatten das früher öfters mal, das bei extrem hohen Latenzen (jenseits von einigen Sekunden, kam nachts, wenn der interne Arbeiten durchgeführt hat) der mal weggestürzt ist. Aber die Zeiten sind zum Glück vorbei. Wie gesagt, serverseitig nichts außergewöhnliches zu erkennen.
Jan
Re: Interpretation xppfatal
Verfasst: Mo, 27. Nov 2017 16:38
von Wolfgang Ciriack
Das ist genau der Fehler, mit dem ich zur Zeit auch kämpfe
EH:1006 two many memory-objects: there are not enough handles
Re: Interpretation xppfatal
Verfasst: Mo, 27. Nov 2017 17:29
von AUGE_OHR
hm ...
MOM Fehler treten doch dann auf wenn ich "massive" Memory Handle "verliere".
wenn ich ein riesiges Array habe oder eine Listbox "normal" mit 1.000.000 Einträgen fülle dann werden die Memory Handle "knapp".
das Problem ist aber meistens erst später "wenn der Speicher noch nicht freigegeben" wurde ... und das kann dauern.
weite Möglichkeiten von "Verlust" an Memory Handle
wird BAP verwendet ?
wird XbpPrintDialog:Open() / o:SaveAs() verwendet ?
wird NoIVar verwendet ?
wird XbpListBox:SetData() verwendet ?
statt eines XppFatal.LOG kann man auch ein PopUp verwenden
Code: Alles auswählen
Error():SetErrorMode( ERR_MODE_GUI, ERR_ACTION_POPUP )
Re: Interpretation xppfatal
Verfasst: Mo, 27. Nov 2017 18:37
von DelUser01
Hallo Jan
Jan hat geschrieben: ↑Mo, 27. Nov 2017 15:08das ist ein Programm, das 24/7 durchläuft...Durch die betreffende Codesrequenz geht der ca. 40 - 80x/Minute
Wenn Dein Programm im Dauerbetrieb die Funktionen ausführt haben möglicher Weise alle beteiligten Komponenten nicht ausreichend Zeit so etwas wie "Garbage Collection" durchzuführen.
Kannst Du nicht herausfinden, ob es 1x in der Woche einen Zeitpunkt gibt, in dem ein vollständiger Neustart Deines Programms möglich ist? (z.B: Sonntagmorgen 3 Uhr). Vermutlich würde das Dein Problem umgehen.
Von MS traue ich nur den Server-Betriebssystemen Dauerbetrieb über Monate zu. Wenn es geht wird jeder Server trotz in unregelmäßigen Abständen (1-3 Monate) neu gestartet.
Re: Interpretation xppfatal
Verfasst: Mi, 29. Nov 2017 13:02
von Klaus Schuster
Roland, solltest Du Recht haben, so sollte es doch helfen, alle Variablen am Ende einer Function auf NIL zu setzen.
Re: Interpretation xppfatal
Verfasst: Mi, 29. Nov 2017 13:26
von Jan
Moin,
in dem relativ kleinen Programm (inkl. Kommentare und Function-Header gerade mal gut 900 Zeilen) gibt es insgesamt nur 3 PUBLICs - den nSocket, die ADS-Session, und eine, die ich mal wegräumen könnte weil die nicht mehr verwendet wird. Alles andere sind LOCALs. Alles im Code genutzten Variablen sind wie immer bei mir sauber initialisiert. Es gibt auch nur drei Objekte - Objekte werden von mir standardmäßig nach einem :destroy() immer geNILt, aber hier bleiben die Objekte alle die komplette Laufzeit bestehen. Und LOCALs NILen?
Die Hauptschleife läuft über ein Socket-Auslesen. Nach jedem empfangenen Zeichen kommt die oben zitierte Inkey(0.01). Das sollte also vermutlich ausreichen, um dem Garbage-Collector ein wenig Zeit zum Aufräumen zu gewähren.
Ich seh so also eher weniger Angriffspunkte, wo ich etwas korrigieren oder verbessern könnte.
Ich hatte mir allerdings überlegt, ob ich eventuell den MemWatch mal mit einbinde. Wenn ich da jeden Tag mal schnell einen Blick drauf werfe dann sehe ich ja, ob sich da irgendwas negativ entwickelt.
Jan
Re: Interpretation xppfatal
Verfasst: Mi, 29. Nov 2017 14:36
von brandelh
Ich denke dass hier nur eine Anfrage bei Alaska Erleuchtung bringen kann.
Normale Xbase++ Aktionen sollten nie zu einem Fatal Error führen.
Re: Interpretation xppfatal
Verfasst: Mi, 29. Nov 2017 20:59
von DelUser01
Jan hat geschrieben: ↑Mi, 29. Nov 2017 13:26in dem relativ kleinen Programm...
Die Größe Deines Codes ist allein nicht entscheidend.
Die Hauptschleife läuft über ein Socket-Auslesen....
dahinter stecken ja viele weitere Funktionen bis Du das empfangene Zeichen in deinem String hast.
Nach jedem empfangenen Zeichen kommt die oben zitierte Inkey(0.01). Das sollte also vermutlich ausreichen, um dem Garbage-Collector ein wenig Zeit zum Aufräumen zu gewähren.
wenn Du einen sehr schnellen Rechner mit einigen Kernen verwendest kann bei Inkey(0.01) schon manches passieren. Sonst ist das nicht viel Zeit.
MemWatch...dann sehe ich ja, ob sich da irgendwas negativ entwickelt.
Das muss nicht sein, wenn Zähler, Schleifen, Stacks u.ä. überlaufen merkst Du das vermutlich nicht am Speicher.
Re: Interpretation xppfatal
Verfasst: Mi, 29. Nov 2017 21:43
von AUGE_OHR
Jan hat geschrieben: ↑Mo, 27. Nov 2017 15:08das ist ein Programm, das 24/7 durchläuft. Manchmal wochenlang ohne Probleme.
ich frage mich wozu es ECC-RAM gibt ...
Re: Interpretation xppfatal
Verfasst: Sa, 02. Dez 2017 23:17
von UliTs
Jan hat geschrieben: ↑Mi, 29. Nov 2017 13:26
Moin,
in dem relativ kleinen Programm (inkl. Kommentare und Function-Header gerade mal gut 900 Zeilen) gibt es insgesamt nur 3 PUBLICs - den nSocket, die ADS-Session, und eine, die ich mal wegräumen könnte weil die nicht mehr verwendet wird. Alles andere sind LOCALs. Alles im Code genutzten Variablen sind wie immer bei mir sauber initialisiert. Es gibt auch nur drei Objekte - Objekte werden von mir standardmäßig nach einem :destroy() immer geNILt, aber hier bleiben die Objekte alle die komplette Laufzeit bestehen. Und LOCALs NILen?
Die Hauptschleife läuft über ein Socket-Auslesen. Nach jedem empfangenen Zeichen kommt die oben zitierte Inkey(0.01). Das sollte also vermutlich ausreichen, um dem Garbage-Collector ein wenig Zeit zum Aufräumen zu gewähren.
Ich seh so also eher weniger Angriffspunkte, wo ich etwas korrigieren oder verbessern könnte.
Ich hatte mir allerdings überlegt, ob ich eventuell den MemWatch mal mit einbinde. Wenn ich da jeden Tag mal schnell einen Blick drauf werfe dann sehe ich ja, ob sich da irgendwas negativ entwickelt.
Jan
Kannst Du nicht statt Public Static einsetzen?
Dann könntest Du täglich den Task Manager aufrufen und Dir die Werte der Handles, GDI-Objekte, Threads und Arbeitsspeicher des Programms aufschreiben. Vielleicht fällt da noch etwas auf.