Wieder mal ein XppFatal

[Jan]

Kann einer der Spezialisten mir sagen, was mir diese Fehlermeldung sagen möchte:

Code: Alles auswählen

FATAL ERROR LOG 
Not recoverable Error!
SYS Thread-ID: 640 
Module: EH
Error Codes: EH: 900 Sub: 0(0) OS: 0 XPP: 0
Call Stack of Thread 1 (544):
MAIN(304)
Call Stack of GUI Thread (728):
Call Stack of Thread 3 (968):
Call Stack of Thread 4 (1236):
Call Stack of Thread 5 (1444):
FUNKTION2(1205)
(B)Funktion1(196)
@XBPPUSHBUTTON@I@HANDLEEVENT(987)
Funktion1(280)
File: E:\Programme\Programm.exe
TimeStamp: 20120526 19:12
End of FATAL ERROR LOG.

Der Fehler ist reproduzierbar. Eventuell wegen zu großer Arrays? Die MemoryHandles gehen laut MemoryWatcher auf ca. 1,4 Mio. hoch. In Zeile 1205 gibt es übrigens nur eine Abfrage, die sauber durchlaufen wird. Der Fehler tritt erst irgendwo danach auf. Auf was die Zeilen in Threads 3, 4, und 5 verweisen kann ich nicht sagen. Denn in der Schleife nach Zeile 1205 wird zwar eine Funktion in einem anderen Thread aufgerufen, die hat aber nur gut 800 Zeilen.

Jan

[Martin Altmann]

Moin,
die Nummern nach den Threads sind die Prozess-IDs - keine Zeilennummern!

Viele Grüße,
Martin

[Jan]

Ah! OK, so verstehe ich die Aufstellung auch besser.

Jan

[Tom]

Die Threads ohne nachfolgende Zeilennummern sind Systemthreads wie der GUI-Thread, der Eventmanager-Thread (EVM) usw. Der Fehler tritt im Errorhandling selbst auf ("Module: EH"), wie ich - vermutlich richtig - vermute. Wenn es sich tatsächlich (auch bei Dir vor Ort) reproduzieren lässt und Du eine modifizierte Errorsys verwendest, würde ich empfehlen, mal die Standard-Errorsys zu linken und zu schauen, was mit der passiert.

[Jan]

Hallo Tom,

wieder einmal hattest Du Recht. Jetzt gibt es keine XppFatal mehr. Allerdings auch sonst keine Fehlermeldung mehr

Jan

[Tom]

Willst Du damit sagen, dass Deine Applikation jetzt an der fraglichen Stelle sang- und klanglos abschmiert?

[Jan]

Jupp

Jan

[AUGE_OHR]

Code: Alles auswählen

FATAL ERROR LOG 
Not recoverable Error!
SYS Thread-ID: 640 
Module: EH
Error Codes: EH: 900 Sub: 0(0) OS: 0 XPP: 0
Call Stack of Thread 1 (544):
MAIN(304)
Call Stack of GUI Thread (728):
Call Stack of Thread 3 (968):
Call Stack of Thread 4 (1236):
Call Stack of Thread 5 (1444):
FUNKTION2(1205)
(B)Funktion1(196)
@XBPPUSHBUTTON@I@HANDLEEVENT(987)
Funktion1(280)
File: E:\Programme\Programm.exe
TimeStamp: 20120526 19:12
End of FATAL ERROR LOG.

hi,

mir fällt auf das du den GUI Thread angezeigt bekommst. rufst du da ein activeX oder per DllCall was auf ?

[Jan]

Hallo Jimmy,

ja, in meiner eigenen Errorsys ist ein DllCall drin - für blat.

Jan

[brandelh]

ich würde die Errorsys nicht zum Versand von eMail nutzen.
Wenn beim Programmstart eine XppError.log vorhanden ist, würde ich fragen ob man diese an den Support eMailen will

[Jan]

Hubert,

bislang funktioneirt das sehr gut und zuverlässig. Ich denke, diese XppFatal kommt deswegen zustande, weil der eigentliche Fehler so überhaupt garnicht abgefangen werden kann.

Der Sinn des mailversandes ist, das im Fehlerfall in meinem Programm sofort eine Mail an mich rausgehen kann. Was wie gesagt sehr gut und zuverlässig funktioniert.

Es ist offensichtlich nicht der Fehler in der XppFatal mein Problem, sondern das eigentliche Problem. Und ich glaube, ich habe es einkreisen können. Ich verwende den Hotfix 36, um die Anzahl der Arrayelemente auf über 4 Mio. hochsetzen zu können. Gerade das scheint aber nicht mehr zu funktionieren. Die DLL habe ich kontrolliert - die ist korrekt. Aber im Memwatcher kann ich sehen, daß der Absturz bei ca. 4 Mio. Handles kommt. Das würde passen. Stellt sich nur die Frage - warum?

Jan

[brandelh]

bislang funktioneirt das sehr gut und zuverlässig. Ich denke, diese XppFatal kommt deswegen zustande, weil der eigentliche Fehler so überhaupt garnicht abgefangen werden kann.

Je nach Fehlersituation ist nicht mehr viel möglich (Speicher voll, unerklärlicher Fehler zerschießt den Stack, ...) daher
halte ich die XppError.LOG so einfach wie möglich um die Gefahr von Fehlern in der Fehlerbehandlung zu minimieren.

Der Sinn des mailversandes ist, das im Fehlerfall in meinem Programm sofort eine Mail an mich rausgehen kann. Was wie gesagt sehr gut und zuverlässig funktioniert.

Warum du das machst ist mir schon klar, aber offensichtlich funktioniert es nicht immer
Aus den genannten Gründen lagere ich den Versand ins Hauptprogramm um.

Es ist offensichtlich nicht der Fehler in der XppFatal mein Problem, sondern das eigentliche Problem. Und ich glaube, ich habe es einkreisen können. Ich verwende den Hotfix 36, um die Anzahl der Arrayelemente auf über 4 Mio. hochsetzen zu können.

Genau, eine XppFatal.log entsteht immer - wenn auch nicht ausschließlich, wenn ein Fehler im ErrorHandler zu

Stellt sich nur die Frage - warum?

Weil dir offensichtlich die Handles oder Resourcen ausgehen. 4 Millionen Datensätze im Array ... du solltest den Ansatz überdenken

[Martin Altmann]

Ähem!
Wenn eine XPPFATAL entstehen würde, könnte eh' keine Mail mehr versandt werden - dann ist das Programm schon tot!
Das Versenden, so wie Jan das realisiert hat, kann nur bei XPPERROR.LOGs funzen!

Viele Grüße,
Martin

[Tom]

Ich möchte Hubert energisch widersprechen. Wenn ein Laufzeitfehler auftritt, dann ist das mit weit mehr als 99prozentiger Wahrscheinlichkeit ein Syntaxfehler, eine falsch typisierte Variable, ein fehlender Parameter, ein fehlendes Datenbankfeld, eine nicht selektierte Workarea oder ähnliches. Das Laufzeitfehlersystem wird letztlich von einer noch funktionierenden Anwendung aufgerufen, die lediglich an einer "falschen Stelle" dorthin verzweigt, und es ist keineswegs so, dass die Applikation zu diesem Zeitpunkt irgendwie instabil wäre. Das ist maximal bei absurd unwahrscheinlichen Fehlern ("Nicht genügend Arbeitsspeicher" o.ä.) der Fall, die ohnehin dazu führen dürften, dass der ja ziemlich aufwendige Prozess, eine Standard-XppError.log zu schreiben, ebenfalls scheitert. Genau dieser Tatsache trägt der Umstand, dass man das Laufzeitfehlersystem selbst bestücken kann, ja Rechnung. Wenn man dort nun Variablen oder Objekte referenziert, die noch nicht initialisiert sind, oder irgendwas anderes Staatstragendes macht, das möglicherweise selbst Fehlerursache ist, hat man zweifelsohne ein Problem. Aber dieser Zustand ist erstens vermeidbar und zweitens im Normalfall eben eine absolute Ausnahme. Ich sorge beim Programmstart dafür, dass das Fehlersystem alles weiß, was es wissen muss, um Faxe und Mails zu versenden oder in unsere Fehlerdatenbank zu verzweigen, und wenn es eben noch nicht alles weiß, was so gut wie nie eintritt, wird eben nur rudimentär geloggt. Aber, wie gesagt - die App ist nicht instabil, wenn sie in das Fehlersystem verzweigt. Jedenfalls in den allermeisten Fällen nicht. Sonst liefe das Fehlersystem auch nicht mehr, egal, in welcher Ausbaustufe.

[Jan]

Da mein Programm ansich keine fatals erzeugt, ist mir egal, ob da eine Mail versendet wird.

Und nein. Eine xppfatal wird eben nicht immer erzeugt. Z. B. in meinem Fall, wenn ich den Standard-Errorsys nehme. Dann kann ich meine gesamte Festplatte absuchen, da ist keine.

Wo ist das Problem mit der Anzahl der Array-Elemente? Genau der Punkt wird doch mit dem Hotfix 36 gelöst.

Jan

[brandelh]

Ich möchte Hubert energisch widersprechen.

Rufst du dort FREMD-DLLs auf ?

Ich stimme dir zu, dass die von mir beschriebenen kritischen Fehler unter Xbase++ wesentlich seltener sind als unter Clipper.
Und natürlich kann man mit viel Sorgfalt Fehler in der Fehlerbehandlung vermeiden, genauso wie im restlichen Programm

Dennoch finde ich es nicht sinnvoll, dass in der Fehlerbehandlung direkt eMails versandt werden.
Die XppFatal.LOG und die XppError.LOG versendet mein Hauptprogramm beim Programmstart wenn es eine der Dateien findet nach Rückfrage (das kann man auch anders machen.)
Ob ich den Fehler einige Minuten früher erhalte, was solls. Selbst verständlich kann man das machen wie man will

[Tom]

Rufst du dort FREMD-DLLs auf ?

Jede Menge. Sogar direkt aus der Errorsys.

[AUGE_OHR]

Rufst du dort FREMD-DLLs auf ?

Jede Menge. Sogar direkt aus der Errorsys.

WOW ... dann "vertraust" du dem OS() aber ein Menge zu !

Einen Fehler der bis zur Errorsys gekommen ist und nicht vorher abfangen wurde ist schon ein Log Eintrag wert aber dann kommt es auch auf den Fehler an ob es "sinnvoll" ist die Application weiter laufen zu lassen oder man den PC dann "re-booted" wie bei einem XppFatal.LOG

ein XppFatal erhalte ich doch dann wenn er nicht in Xbase++ durch XBPException():RaiseParameterXXX(xValue) abgefangen wurde und deshalb die Errorsys nicht zu Zuge kommt.

p.s. ich verwende ADDITIVE und "versende" die Errorlogs nicht "sofort" sondern nur 1x täglich nach dem Backup

[AUGE_OHR]

Wo ist das Problem mit der Anzahl der Array-Elemente? Genau der Punkt wird doch mit dem Hotfix 36 gelöst.

hm ... meinst du PDR 6235 ? wie muss man das "einstellen" um das zu reproduzieren ?

[Jan]

Jimmy,

frag bei Alaska an. Es gibt da eine ganz offizielle Anleitung für, die die Dir sicher gerne zumailen. Wenn die nicht sogar irgendwo in deren Papers auf dem ftp-Server veröffentlicht ist, das weiß ich nicht.

Jan

[AUGE_OHR]

PDR 6235

By default the Xbase++ runtime can manage 2000000 memory objects.
Allthough this is sufficient in most cases, it is desirable to customize
this number. For example, in cases where huge (multi dimansional) arrays
are used to collect information for further processing it can be necessary
to have a higher number of memory objects available.

besagt ja nur das es default 2 Mio. sind.

wenn du nun bei 4 Mio. angelangt bist ist das wohl wieder so eine 32bit Grenze die du erreicht haben könntest...

[Jan]

Jimmy,

richtig, da habe ich mich falsch erinnert. Die Grenze, die Alaska gezogen hat, lag bei 2 Mio, nicht bei 4. Stellt sich mir die Frage: Warum stürzt das Programm bei gut 4 Mio. ab, ohne XppError und ohne XppFatal? An einer Stelle, an der das früher reibungslos durchlief? Muß ich mal weiter auf die Suche gehen. Mist.

Ich habe in dem betreffenden Programm die Grenze übrigens auf 8 Mio. Handles hochgesetzt. Ohne den von Alaska befürchteten Nachteil einer Verlangsamung des Programms.

Jan

[brandelh]

wenn du nun bei 4 Mio. angelangt bist ist das wohl wieder so eine 32bit Grenze die du erreicht haben könntest...

die 32bit Grenze liegt bei 2 (long) bzw. 4 (dword) Milliarden

[Tom]

WOW ... dann "vertraust" du dem OS() aber ein Menge zu !

Ich traue dem OS genau das zu, was es auch können sollte. Und ich fahre exzellent damit.

Das Laufzeitfehlersystem von Xbase++ hat den bestechenden Vorteil, innerhalb einer im Prinzip "gesunden" Applikation zu laufen. Viele Fehler kann man auch aktiv abfangen und umgehend reparieren, beispielsweise fehlerhafte Dateistrukturen, nicht selektierte Workareas aufgrund von verlorengegangenen Serververbindungen, Probleme beim Reindexieren/Öffnen von Indexen durch falsch konfigurierte bzw. überaktive Virenscanner usw. usf. Das Fehlersystem sagt im Prinzip nur: Hey, hier ist etwas, das normalerweise nicht sein dürfte - was soll ich tun? Auf eine Division durch Null, die mathematisch nicht definiert ist, reagieren wir - wahrscheinlich allesamt - dadurch, dass wir das Fehlersystem behaupten lassen, das Ergebnis wäre wiederum Null. Aber es ist keineswegs so, dass der Aufruf des Fehlersystems bedeutet, dass die Applikation oder gar das Betriebssystem instabil wäre. Es gibt fraglos Fehlersituationen und -fälle, bei denen man sehr vorsichtig agieren muss, wozu IDSCs gehören und ein paar Dinge, die mit AX-Objekten zu tun haben. Generell aber ist der Aufruf des Fehlersystems als eine "natürliche" Reaktion auf nicht definierte Zustände zu verstehen. Ich versuche, ein Datenbankfeld zu schreiben, das nicht existiert. Ich greife auf eine Variable zu, die den falschen Typ hat. Ich habe einen Parameter an eine Funktion übergeben, der den falschen Wert hat - oder einen Parameter vergessen. Das alles ist nichts, das einen zum sofortigen Notstopp des gesamten Systems verleiten muss. Und die App läuft weiterhin. Einen vernünftigen Grund dafür, deshalb im Fehlersystem besonders sensibel zu agieren, kann ich nicht erkennen. Die Vermeidung von "intensivem Code" ist absurd und nicht begründbar. Alles ist fein - es ist nur eine Situation eingetreten, die nicht vorhergesehen war, aber alles läuft nach wie vor. Natürlich muss man "by design" vermeiden, dass das Fehlersystem wiederum Funktionen aufruft, die selbst Ursache für Fehler sein können. Aber auch das lässt sich problemlos abfangen.

Fatals sind ein anderes Problem. Die etwas haarige Idee, nach einem Fatal einfach den Rechner zu booten, erinnert mich jedoch an Zeiten, wo man noch froh war, dass die Kiste überhaupt gestartet ist. Jemanden, der mir eine solche Software verkaufen würde, würde ich sofort nach der Auslieferung verklagen.

[brandelh]

Hallo Tom,

grundsätzlich hast du Recht, das Xbase++ Fehlersystem ist eine gute Sache und man kann viel dort erledigen.
Sicherlich ist meine Auffassung noch sehr "Clipper"-lastig, von fehlenden Filehandles bis zu fehlendem freien RAM, jede Menge Fehlermöglichkeiten, die unter Xbase++ nicht mehr existieren.
Dennoch bleibe ich dabei eine "schlanke" ErrorSys zu halten und LOGGE nur Fehler um sie zu beheben.

Einen vernünftigen Grund dafür, deshalb im Fehlersystem besonders sensibel zu agieren, kann ich nicht erkennen.
Die Vermeidung von "intensivem Code" ist absurd und nicht begründbar.

hier bin ich aber anderer Meinung. Jeder Fehler im ErrorHandler ist eine potentielle Endlosschleife mit XppFatal am Ende (wenn der Stack vollgelaufen ist).
Es ist also schon sinnvoll diese Funktion überschaubar zu halten.

Natürlich muss jeder selbst wissen, was für ihn noch überschaubar ist