Debugger: interne Datenstrukturen beschädigt
Moderator: Moderatoren
Debugger: interne Datenstrukturen beschädigt
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?
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
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Debugger: interne Datenstrukturen beschädigt
sehr alt ...Greenhorn hat geschrieben:(Version 1.82.294)
kein Wunder bei 10x3600 wenn du es so aufbaust.Greenhorn hat geschrieben: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:
baue erst, per AADD() ein 3600 Array, dann per ACLONE() die weiteren 9 Arrays und erst dann "füllst" du die mit LIES_ZEITREIHE()
trotzdem ist ein Upgrade auf v1.9.355 dringendst zu empfehlen !!!Greenhorn hat geschrieben: ------------------------------------------------------------------------------
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!
gruss by OHR
Jimmy
Jimmy
- brandelh
- Foren-Moderator
- Beiträge: 15710
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 73 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: Debugger: interne Datenstrukturen beschädigt
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.
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.
Gruß
Hubert
Hubert
Re: Debugger: interne Datenstrukturen beschädigt
Hi,
zunächst vielen Dank für die Antworten.
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?
zunächst vielen Dank für die Antworten.
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.AUGE_OHR hat geschrieben: 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 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?
Seltsamerweise läuft das in 1.80! war die denn stabiler als die neuere 1.82?brandelh hat geschrieben: 1. Auch in Xbase++ sind natürlich Fehler enthalten, die 1.90.xxx soll stabiler sein als die 1.82.xxx
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?brandelh hat geschrieben: 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.
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 hat geschrieben: 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.
- brandelh
- Foren-Moderator
- Beiträge: 15710
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 73 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: Debugger: interne Datenstrukturen beschädigt
Die Antwort ist einfach, das waren die Variablen die dBase und Clipper schon immer kannten.Greenhorn hat geschrieben: Nur frage ich mich, wofür es PRIVATEs oder PUBLICs gibt, wenn die nicht sicher sind?
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.
Ich war mit 1.82 sehr zufrieden, bis ich auf 1.90 umgestiegen binGreenhorn hat geschrieben: Seltsamerweise läuft das in 1.80! war die denn stabiler als die neuere 1.82 ?
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 ...
Gruß
Hubert
Hubert
- Jan
- Marvin
- Beiträge: 14662
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Debugger: interne Datenstrukturen beschädigt
Wie wär es denn, den Debugger aus VX zu verwenden? Der ist ohnehin umfangreicher als der "normale".
Jan
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Re: Debugger: interne Datenstrukturen beschädigt
Hallo Jan,
Viele Grüße
Peter
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.Jan hat geschrieben:Wie wär es denn, den Debugger aus VX zu verwenden? Der ist ohnehin umfangreicher als der "normale".
Jan
Viele Grüße
Peter
- Jan
- Marvin
- Beiträge: 14662
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Debugger: interne Datenstrukturen beschädigt
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
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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- brandelh
- Foren-Moderator
- Beiträge: 15710
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 73 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: Debugger: interne Datenstrukturen beschädigt
Hallo Jan,Jan hat geschrieben:Ich muß aber gestehen, daß die "internen Datenstrukturen beschädigt" meist auftraten, wenn ich wirklich einen Fehler gemacht habe.
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
Gruß
Hubert
Hubert
- Jan
- Marvin
- Beiträge: 14662
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Debugger: interne Datenstrukturen beschädigt
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
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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Re: Debugger: interne Datenstrukturen beschädigt
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:
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
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:
AUGE_OHR hat geschrieben: 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()
Daher habe ich beides getestet mit folgendem Resultaten:Jan hat geschrieben: 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++?
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