Debugger: interne Datenstrukturen beschädigt

[Greenhorn]

Hallo Leute,
habe ein bösartiges Problem: Bei einem Programm meldet sich der Debugger (Version 1.82.294) mit der Meldung "interne Datenstrukturen beschädigt", sobald ich eine PUBLIC-Variable ansehe. Habe das Programm zusammengestutz, so dass ich den Fehler leichter reproduzieren kann:

PROCEDURE MAIN()
PRIVATE aStamm := {}, aKurs := {}, aFehler := {}
LIES_MEHRERE_ZEITREIHEN()
RETURN

PROCEDURE APPSYS
RETURN

FUNCTION LIES_ZEITREIHE(anDatenArray)
LOCAL nPos := 0
FOR nPos = 1 TO LEN(anDatenArray)
anDatenArray[nPos] := nPos
NEXT
RETURN .T.

PROCEDURE LIES_MEHRERE_ZEITREIHEN()
MEMVAR aKurs, aStamm, aFehler
LOCAL nPos := 0, nArrayLen := 3600

FOR nPos = 1 TO 10
AADD(aKurs, ARRAY(nArrayLen))
LIES_ZEITREIHE(aKurs[LEN(aKurs)])
NEXT

RETURN

Der Absturz tritt auf, wenn ich folgendes durchführe: Debugger starten, Im Monitor die PRIVATE-Variablen anklicken, Breakpoint setzen auf die drittletzte Zeile (also LIES_ZEITREIHE(aKurs...), mit F5 starten. Nach zwei Schleifendurchläufen stürtzt das ganze mit o.g. Meldung und folgendem Errorlog ab:

------------------------------------------------------------------------------
FEHLERPROTOKOLL von "P:\Xbase\test5.exe" Datum: 01.12.2009 09:36:58

Xbase++ Version : Xbase++ (R) Version 1.82.294
Betriebssystem : Windows XP 05.01 Build 02600 Service Pack 3
------------------------------------------------------------------------------
oError:args :
oError:canDefault : N
oError:canRetry : N
oError:canSubstitute: N
oError:cargo : NIL
oError:description : Interne Datenstrukturen beschädigt
oError:filename :
oError:genCode : 41
oError:operation :
oError:osCode : 0
oError:severity : 2
oError:subCode : 5
oError:subSystem : BASE
oError:thread : 1
oError:tries : 0
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------
Aufgerufen von LIES_MEHRERE_ZEITREIHEN(31)
Aufgerufen von MAIN(4)

Jetzt kommt der Knüller. Benutze ich mein altes Xbase++ (Ver. 1.80.284) läuft es problemlos!

Habe ich da irgendwas mit den array´s angestellt, das Xbase nicht mag? Wenn ich die Arrays als LOCAL deklariere und entsprechend als Funktionswert übergebe läuft es problemlos. Mit PUBLIC oder PRIVATE stürtz es ab. Das Programm selber (ohne Verwendung des Debuggers) läuft auch völlig fehlerfrei, obwohl die Arrays durchaus mehr als 1Mio. Elemente enthalten können. Kann sich jemand darauf einen Reim machen?

[AUGE_OHR]

(Version 1.82.294)

sehr alt ...

LOCAL nPos := 0, nArrayLen := 3600
FOR nPos = 1 TO 10
AADD(aKurs, ARRAY(nArrayLen))
LIES_ZEITREIHE(aKurs[LEN(aKurs)])
NEXT
RETURN

Der Absturz tritt auf, wenn ich folgendes durchführe: Debugger starten, Im Monitor die PRIVATE-Variablen anklicken, Breakpoint setzen auf die drittletzte Zeile (also LIES_ZEITREIHE(aKurs...), mit F5 starten. Nach zwei Schleifendurchläufen stürtzt das ganze mit o.g. Meldung und folgendem Errorlog ab:

kein Wunder bei 10x3600 wenn du es so aufbaust.
baue erst, per AADD() ein 3600 Array, dann per ACLONE() die weiteren 9 Arrays und erst dann "füllst" du die mit LIES_ZEITREIHE()

------------------------------------------------------------------------------
FEHLERPROTOKOLL von "P:\Xbase\test5.exe" Datum: 01.12.2009 09:36:58

Xbase++ Version : Xbase++ (R) Version 1.82.294
Betriebssystem : Windows XP 05.01 Build 02600 Service Pack 3
------------------------------------------------------------------------------
oError:args :
oError:canDefault : N
oError:canRetry : N
oError:canSubstitute: N
oError:cargo : NIL
oError:description : Interne Datenstrukturen beschädigt
oError:filename :
oError:genCode : 41
oError:operation :
oError:osCode : 0
oError:severity : 2
oError:subCode : 5
oError:subSystem : BASE
oError:thread : 1
oError:tries : 0
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------
Aufgerufen von LIES_MEHRERE_ZEITREIHEN(31)
Aufgerufen von MAIN(4)

Jetzt kommt der Knüller. Benutze ich mein altes Xbase++ (Ver. 1.80.284) läuft es problemlos!

trotzdem ist ein Upgrade auf v1.9.355 dringendst zu empfehlen !!!

[brandelh]

Hi,

oError:description : Interne Datenstrukturen beschädigt deutet auf einen schweren internen Fehler hin,
der eigentlich nicht vorkommen sollte ... warum genau, weiß wohl niemand wirklich, aber es gibt schon
Möglichkeiten sich das Leben leichter zu machen und die Gefahr geringer zu halten:

1. Auch in Xbase++ sind natürlich Fehler enthalten, die 1.90.xxx soll stabiler sein als die 1.82.xxx
2. PRIVATE und PUBLIC sind maximal als READ ONLY akzeptabel, schon seit Clipper 5.0 sollte man auf LOCAL umstellen.
Wenn man etwas Zentral braucht, kann man eine Funktion mit STATICs nutzen oder gleich Instanzvariablen im Fenster anlegen.
3. Wenn es nur im Debugger kracht und die Stelle uninteressant ist, könnte man da wo es interessant ist ein altd() setzen und vorher mit F5 überspringen.

[Greenhorn]

Hi,
zunächst vielen Dank für die Antworten.

kein Wunder bei 10x3600 wenn du es so aufbaust.
baue erst, per AADD() ein 3600 Array, dann per ACLONE() die weiteren 9 Arrays und erst dann "füllst" du die mit LIES_ZEITREIHE()

Das geht in diesem Fall nicht. Das (Original-)Programm liest Kursreihen von Börsenkursen ein, wobei sich erst beim Einlesen herausstellt, ob Kurse im untersuchten Bereich vorhanden sind, also (unter Benutzung des Datums als Array-Index) abgespeichert werden können. Und da die Kursreihen immer Lücken haben, hielt ich es für sinnvoller, direkt ein (mit NIL) gefülltes Array anzuhängen und dann nur die Stellen zu füllen, für die Daten vorhanden sind.

Das Füllen mit dem Schleifenindex in diesem Testprogramm ist nur eine Vereinfachung, um die Fehlerquelle einzugrenzen.

Ohne Debugger läuft das Programm bisher mit Hunderten von Kursreihen á 4000 Werten problemlos. Wieso?

1. Auch in Xbase++ sind natürlich Fehler enthalten, die 1.90.xxx soll stabiler sein als die 1.82.xxx

Seltsamerweise läuft das in 1.80! war die denn stabiler als die neuere 1.82?

2. PRIVATE und PUBLIC sind maximal als READ ONLY akzeptabel, schon seit Clipper 5.0 sollte man auf LOCAL umstellen.
Wenn man etwas Zentral braucht, kann man eine Funktion mit STATICs nutzen oder gleich Instanzvariablen im Fenster anlegen.

Danke für den Tip. Das könnte eine sinnvolle Lösung sein. Nur frage ich mich, wofür es PRIVATEs oder PUBLICs gibt, wenn die nicht sicher sind?

3. Wenn es nur im Debugger kracht und die Stelle uninteressant ist, könnte man da wo es interessant ist ein altd() setzen und vorher mit F5 überspringen.

Leider kracht der Debugger (bei dem Vollprogramm) fast an jeder Stelle, sobald ich mir eine PRIVATE-Variable ansehe (wenn vorher zumindest ein paar Zeilen im Array gefüllt wurden). Es reicht schon das Anklicken im Monitor-Fenster, und es rumst.

[brandelh]

Nur frage ich mich, wofür es PRIVATEs oder PUBLICs gibt, wenn die nicht sicher sind?

Die Antwort ist einfach, das waren die Variablen die dBase und Clipper schon immer kannten.
Bei Interpretern (dBase) ging es gar nicht anders. Aber je größer ein Programm wird, desto schwerer kämpft
man mit Nebenwirkungen wenn jede Funktion eine andere Variable ändern kann.

Deshalb wurde bei Clipper 5.0 schon LOCAL eingeführt.

Seltsamerweise läuft das in 1.80! war die denn stabiler als die neuere 1.82 ?

Ich war mit 1.82 sehr zufrieden, bis ich auf 1.90 umgestiegen bin

Möglich, dass mit der 1.82 der Garbage Collector "verbessert" wurde, was dir jetzt Ärger bereitet, KEINE AHNUNG !

Lade doch mal die Testversion von 1.90 herunter und probier was passiert, notfalls nimm die 1.80 wenn sie dir reicht.
Wie gesagt INTERNE DATENSTRUKTUREN sind Fehler die wir nicht beheben können. Wir können nur versuchen die problematischen Aktionen zu umschiffen - was ist problematisch ...

[Jan]

Wie wär es denn, den Debugger aus VX zu verwenden? Der ist ohnehin umfangreicher als der "normale".

Jan

[Greenhorn]

Hallo Jan,

Wie wär es denn, den Debugger aus VX zu verwenden? Der ist ohnehin umfangreicher als der "normale".
Jan

Den habe ich als ersten verwendet und der wird dabei völlig ins Nirvana geschossen, bevor er überhaupt eine Fehlermeldung von sich geben kann, so dass ich ihn mit dem Taskmanager beenden musste. Der "normale" Debugger lieferte immerhin noch die Meldung und das Errorlog-File.

Viele Grüße
Peter

[Jan]

Oops! Nicht gut.

Ich habe persönlich die Erfahrung gemacht das es oftmals hilft, den Code etwas umzustrukturieren. Aus irgendeinem Grund "verknotet" sich Xbase++ anscheinend manchmal. Und ein simples umdehen der Codereihenfolge bringt das wieder in Ordnung. Manchmal.

Ich muß aber gestehen, daß die "internen Datenstrukturen beschädigt" meist auftraten, wenn ich wirklich einen Fehler gemacht habe. Das Problem ist, das die in der Fehlermeldung angegebene Zeilennummer ziemlich garantiert nicht die ist, in der der Fehler wirklich auftritt. Das macht die Fehlersuche nicht unbedingt einfacher. Aber wenn man das im Hinterkopf behält dann beißt man sich wenigstens nicht in der betreffenden Zeile fest, was auch schon mal ein Vorteil ist.

Jan

[brandelh]

Ich muß aber gestehen, daß die "internen Datenstrukturen beschädigt" meist auftraten, wenn ich wirklich einen Fehler gemacht habe.

Hallo Jan,

ich weiß zwar nicht was DU für Fehler machst, aber eindeutig ist eine XppFatal.LOG mit INTERNE STRUKTUREN kein Fehler,
den ein Xbase++ Programmierer durch Syntax etc. Fehler zu verantworten hat. Möglich, dass man Grenzen sprengt, die
man nicht hätte antasten sollen (500 MB im Array bei 512 MB Hauptspeicher etc....), aber laut Beschreibung gibt es ja keine Grenzen

Eigentlich müsste das Xbase++ Fehlersystem alles abfangen, interne Datenstrukturen sind ein Fehler im Internen System ...
Eigene Fehler im XppError.SYS gehen aber natürlich auf einen selbst zurück, die erzeugen aber meist einen Stacküberlauffehler.

PS: JAN, das war jetzt als Entschuldigung für dich gedacht, nur falls es nicht richtig verstanden wurde

[Jan]

Hallo Hubert,

sagen wir mal so: Jeder Fehler, den ich mache, sollte durch einen normalen XppError abgefangen werden. Ein XppFatal sollte einen Fehler von Alaska aufzeigen.

Dennoch habe ich es schon geschafft, so verquere Sachen anzustellen, das ich die internen Datenstrukturen etwas durcheinandergewirbelt habe (um bei dieser Fehlermeldung zu bleiben). Ob das dann wirklich MEIN Fehler war, oder ich nur durch eine etwas unorthodoxe kodierung eine Schwachstelle in Xbase++ gefunden habe, sei dahingestellt. Wie gesagt, es hat schon geholfen, die Reihenfolge von Codezeilen zu ändern. Was eigentlich Blödsinn ist, denn ob ich eine Methode zuerst oder später aufrufe, sollte für das Objekt doch meist egal sein.

Auch durch Arrays habe ich es geschafft, XppFatal auszulösen. Das geht ganz einfach: Einfach auf einen Schlag ein großes Array erzeugen. Nicht mit AAdd(), denn das funktioniert. Ist das nun mein Fehler oder der von Xbase++? Du sprichst es an, lt. Beschreibung ist es nicht meiner.

Wichtig ist aber die Erkenntnis, die ich in meiner vorigen Antwort geschrieben habe: Bei zerstörten internen Datenstrukturen ist die ausgeworfene Codezeile mit größter Wahrscheinlichkeit nicht die Fehlerquelle. Die liegt irgendwo anders davor oder dahinter. So war es jedenfalls fast durchgängig bei mir. Und dann sucht man sich vollkommen umsonst stundenlang einen Wolf.

Jan

[Greenhorn]

Hi,
nochmal ein kleiner Nachtrag, weil ich aus der Diskussion entnehme, dass es anscheinend problematisch ist, wenn man große Arrays mit der "ARRAY"-Funktion direkt erzeugt, anstatt mit AADD() diskret aufzubauen:

kein Wunder bei 10x3600 wenn du es so aufbaust.
baue erst, per AADD() ein 3600 Array, dann per ACLONE() die weiteren 9 Arrays und erst dann "füllst" du die mit LIES_ZEITREIHE()

Auch durch Arrays habe ich es geschafft, XppFatal auszulösen. Das geht ganz einfach: Einfach auf einen Schlag ein großes Array erzeugen. Nicht mit AAdd(), denn das funktioniert. Ist das nun mein Fehler oder der von Xbase++?

Daher habe ich beides getestet mit folgendem Resultaten:
1. Auch der diskrete Aufbau meines Array mit AADD() führt in meinem Fall (solange das Array PRIVATE ist) zum gleichen Absturz des Debuggers, bringt also nix.
2. Das diskrete Aufbauen mit AADD() dauert aber ca. 2,5x so lang, wie mit mit der Funktion ARRAY(). Die ARRAY()-Funktion scheint also sehr effizient programmiert zu sein, so dass sich ihre Nutzung bei großen Array nahezu aufdrängt (hier getestet mit 2-dim Array mit mehreren Tausend Zeilen und Spalten).
3. Letzte Erkenntnis, die zwar nicht direkt zum Problem gehört, die ich aber gleich mit getestet habe: Das testweise Füllen des Arrays mit den Indexzahlen unter Nutzung einer FOR-NEXT-Schleife war immer ca. 5% schneller als die Realisierung durch einen Codeblock mit AEVAL(). Das ist zwar nicht viel, aber aus anderen Diskussionen dieses Forums hatte ich entnommen, dass die Benutzung von AEVAL() schneller sein sollte als eine diskrete Schleife.

Viele Grüße
Peter