Interpretation xppfatal

Alle Fragen um die Programmierung, die sich sonst nicht kategorisieren lassen. Von Makro bis Codeblock, von IF bis ENDIF

Moderator: Moderatoren

Antworten
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Interpretation xppfatal

Beitrag 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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Interpretation xppfatal

Beitrag 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.
Herzlich,
Tom
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Interpretation xppfatal

Beitrag 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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Interpretation xppfatal

Beitrag 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.
Herzlich,
Tom
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Interpretation xppfatal

Beitrag 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.
Gruß
Hubert
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Interpretation xppfatal

Beitrag 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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Wolfgang Ciriack
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2932
Registriert: Sa, 24. Sep 2005 9:37
Wohnort: Berlin
Hat sich bedankt: 13 Mal
Danksagung erhalten: 34 Mal
Kontaktdaten:

Re: Interpretation xppfatal

Beitrag 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
Viele Grüße
Wolfgang
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Interpretation xppfatal

Beitrag 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  )
gruss by OHR
Jimmy
DelUser01

Re: Interpretation xppfatal

Beitrag 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.
Benutzeravatar
Klaus Schuster
Foren-Administrator
Foren-Administrator
Beiträge: 366
Registriert: Do, 24. Jan 2008 10:01
Wohnort: 90762 Fürth
Hat sich bedankt: 9 Mal
Danksagung erhalten: 9 Mal

Re: Interpretation xppfatal

Beitrag von Klaus Schuster »

Roland, solltest Du Recht haben, so sollte es doch helfen, alle Variablen am Ende einer Function auf NIL zu setzen.
Gruß Klaus
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Interpretation xppfatal

Beitrag 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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Interpretation xppfatal

Beitrag 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.
Gruß
Hubert
DelUser01

Re: Interpretation xppfatal

Beitrag 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.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Interpretation xppfatal

Beitrag 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 ... :-"
gruss by OHR
Jimmy
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: Interpretation xppfatal

Beitrag 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.
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Antworten