Inoffizielles deutsches Xbase-Forum

Schönen guten Morgen zusammen,
ich habe folgendes Phänomen...
Nach ausführen einer Unterprozedur endet zu 50% das Programm kommentarlos.

XPPFATAL.LOG:
FATAL ERROR LOG
Not recoverable Error!
SYS Thread-ID: 1260
Module: EH
Error Codes: EH: 900 Sub: 0(0) OS: 0 XPP: 0
Call Stack of Thread 1 (1088):
@XBPCRT@I@HANDLEEVENT(833)
_IINKEY(680)
MAIN(459)
Call Stack of GUI Thread (1260):
Call Stack of Thread 3 (1972):
File: D:\XPP20\PRISMA\k2003\Prisma32\PRISMA32.EXE
TimeStamp: 20200322 09:30
End of FATAL ERROR LOG.

manchmal erscheint auch als Meldung "interne Datenstrukturen beschädigt" (Sind sie aber nicht!)

Aktuell habe ich das Problem behoben, indem ich alle offenen Dateien schließe und neu öffne.

Das behebt zwar den Fehler, aber nicht die Ursache.
Tipps?

Gruß Stefan

Mit reinen Xbase++ Befehlen dürfte kein solcher FATAL Error auftreten,
außer man ruft in einer Endlosschleife Funktionen auf bis der Callstack erschöpft ist.

Ein "interne Datenstrukturen beschädigt" kann man am einfachsten mit DLL Aufrufen erklären, bei denen Parameterfehler auftreten.
Ob es in deinem Fall auch so ist, weiß ich nicht.

Reine XBase Befehle, kein DLL Call.
Deswegen wundere ich mich ja.
Das aufgerufene "Unterprogramm" wird problemlos abgearbeitet.
Nach der Rückkehr zum Hauptmenü treten die Fehler sporadisch auf.

Gruß Stefan

hi,

so wie es aussieht arbeitest du mit CRT und Thread.
da führst du nun eine Unterprozedur auf die vermutlich "intensive" ist ...
dann kommt er aus der Unterprozedur ... und läuft in deine Event Schleife.... was wohl "dein _INKEY()" darstellt.

---

CRT und Thread ist mit "Cl*pper" Style schwer ...
da KEINE Ausgabe im "falschen" Thread passieren darf sind "Wait-State" wie Inkey() sehr Problematisch.
zeige doch bitte mal "deine _INKEY()"

Stefan,

das mit dem "interne Datenstrukturen beschädigt" kenne ich leider auch nur zu gut. Und muß ebenso leider sagen, das ich da keine Idee zu habe. Manchmal scheint Xbase++ sich da einfach zu verknoten. Ab und an hat es bei mir geholfen, einfach den Code etwas umzuschreiben. Das Ergebnis ist dann immer noch das Gleiche, aber alleine diese Umstrukturierung scheint ab und an mal zu helfen. An Fremd-DLL dürfte das zumindest bei mir eher nich liegen, da ich die soweit möglich immer meide. Und ich diese Fehlermeldung auch in Programmen habe, wo eindeutig nichts als Xbase++ läuft.

Wobei ich sagen muß das ich die Meldung in den letzten Monaten hauptsächlich während des Debuggens bekomme. Oftmals dann, wenn ich ein paar Minuten im Debugger nichts gemacht habe. Aber auch in Kunden-Fehlerprotokollen bekomme ich die immer noch ab und an. Aus Codebereichen, die sonst nie Probleme machen.

Insgesamt finde ich das ebenso frustrierend wie den Fehler 8999. Der auch wenig bis gar nicht zielführend ist.

Jan

IDSCs haben m.E. etwas damit zu tun, dass das Speichermanagement von Xbase++ in Schwierigkeiten gerät. IDSCs sollten nachstellbar sein. Sie haben oft etwas mit falscher Parametrisierung zu tun, wie beispielsweise in diesem PDR:

http://www.alaska-software.com/scripts/ ... PDRID=6687

Der Fehler bei Dir, Stefan, tritt im Modul "EH" auf, das ist das Errorhandling. Du generierst wahrscheinlich in _Inkey(680) einen ganz normalen Laufzeitfehler, aber das Fehlersystem kann nicht reagieren. In der steinalten Fehlerübersichts-Hilfedatei steht nur das hier: "Separate Thread, may have different Thread ID in XppFatal.logs" (XppFatal Message: "Not recoverable Error!", - Error Codes: "EH: 900"/"XPP: 0"). Irgendwas mit dem Threadmanagement also.

Das Basisprogramm läuft in diesem Fall noch mit CRT,
alle aufgerufenen Programme mit Windowsoberfläche.
An dem neuen Programmteil scheint es nicht zu liegen,
nehme ich ein anderes "Unterprogramm" raus, tritt der Fehler nach Aufruf des
neuen Moduls nicht mehr auf.
Kann das an der EXE-Größe liegen?
Mit 18,2MB läuft es anstandslos, mit 20,3MB nicht mehr.
Ich starte jetzt einige Module als externe Programme,
bisher ist kein Fehler mehr aufgetreten.

Gruß Stefan