Das Forentreffen 2018 findet am 20./21. April in Dresden statt. Weitere Infos hier
Anmeldungen zum Forentreffen 2018 sind auf der Anmeldeseite möglich
Zur Homepage des Deutschsprachige Xbase-Entwickler e. V.
Xbase++-Wiki des Deutschsprachige Xbase-Entwickler e. V.

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
Foren-Administrator
Foren-Administrator
Beiträge: 12551
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Kontaktdaten:

Interpretation xppfatal

Beitrag von Jan » Mo, 27. Nov 2017 13:29

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
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.

Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 6866
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Kontaktdaten:

Re: Interpretation xppfatal

Beitrag von Tom » Mo, 27. Nov 2017 13:44

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
Foren-Administrator
Foren-Administrator
Beiträge: 12551
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Kontaktdaten:

Re: Interpretation xppfatal

Beitrag von Jan » Mo, 27. Nov 2017 14:35

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
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.

Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 6866
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Kontaktdaten:

Re: Interpretation xppfatal

Beitrag von Tom » Mo, 27. Nov 2017 14:44

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: 13907
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Interpretation xppfatal

Beitrag von brandelh » Mo, 27. Nov 2017 14:58

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
Foren-Administrator
Foren-Administrator
Beiträge: 12551
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Kontaktdaten:

Re: Interpretation xppfatal

Beitrag von Jan » Mo, 27. Nov 2017 15:08

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
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.

Benutzeravatar
Wolfgang Ciriack
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2315
Registriert: Sa, 24. Sep 2005 9:37
Wohnort: Berlin
Kontaktdaten:

Re: Interpretation xppfatal

Beitrag von Wolfgang Ciriack » Mo, 27. Nov 2017 16:38

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: 10738
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: Interpretation xppfatal

Beitrag von AUGE_OHR » Mo, 27. Nov 2017 17:29

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

Benutzeravatar
Roland Gentner
1000 working lines a day
1000 working lines a day
Beiträge: 956
Registriert: Fr, 24. Nov 2006 8:30
Wohnort: Neresheim
Kontaktdaten:

Re: Interpretation xppfatal

Beitrag von Roland Gentner » Mo, 27. Nov 2017 18:37

Hallo Jan
Jan hat geschrieben:
Mo, 27. Nov 2017 15:08
das 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.
Gruß
Roland

Benutzeravatar
Klaus Schuster
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 121
Registriert: Do, 24. Jan 2008 10:01
Wohnort: 90762 Fürth

Re: Interpretation xppfatal

Beitrag von Klaus Schuster » Mi, 29. Nov 2017 13:02

Roland, solltest Du Recht haben, so sollte es doch helfen, alle Variablen am Ende einer Function auf NIL zu setzen.
Gruß Klaus

Alaska? Mein Lieber, da sollten Sie sich warm anziehen!

Benutzeravatar
Jan
Foren-Administrator
Foren-Administrator
Beiträge: 12551
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Kontaktdaten:

Re: Interpretation xppfatal

Beitrag von Jan » 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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 13907
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Interpretation xppfatal

Beitrag von brandelh » Mi, 29. Nov 2017 14:36

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

Benutzeravatar
Roland Gentner
1000 working lines a day
1000 working lines a day
Beiträge: 956
Registriert: Fr, 24. Nov 2006 8:30
Wohnort: Neresheim
Kontaktdaten:

Re: Interpretation xppfatal

Beitrag von Roland Gentner » Mi, 29. Nov 2017 20:59

Jan hat geschrieben:
Mi, 29. Nov 2017 13:26
in 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.
Gruß
Roland

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 10738
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: Interpretation xppfatal

Beitrag von AUGE_OHR » Mi, 29. Nov 2017 21:43

Jan hat geschrieben:
Mo, 27. Nov 2017 15:08
das 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: 2477
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Kontaktdaten:

Re: Interpretation xppfatal

Beitrag von UliTs » Sa, 02. Dez 2017 23:17

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