Inoffizielles deutsches Xbase-Forum

Moin,

ich kämpfe gerade mit einem merkwürdigen Fehler. Ich arbeite einen größeren String ab (180 MB groß) und speichere die Bestandteile in einer dbf. Dabei kommt es reproduzierbar immer an der gleichen Stelle zu einem Absturz. Es ist ein Satz abgearbeitet, ein neuer soll appended werden. Sowohl ein DbAppend() als auch ein DbRUnLock() als auch andere Db-Funktionen bewirken den Absturz. Und das selbst dann, wenn ich diese DB-Funktion in eine Sequence-Schleife lege. Klar, das gibt ja keinen Laufzeitfehler sondern einen fatalen.

Die xppfatal beginnt so:

FATAL ERROR LOG
in function: atmStartGCThread(void*)
SYS Thread-ID: 652
Module: ATM
Error Codes: EH: 5 Sub: -1073741819(c0000005) OS: 0 XPP: 41
Call Stack of Thread 1 (608):

Kann jemand mit erzählen, was da schief läuft?

Jan

hast Du Dir das mal im Debugger angeschaut, was da passiert?

Hallo Manfred,

ja natürlich. Ich stehe auf der Zeile mit dem DbAppend() (oder einer beliebigen anderen DB-Funktion), drücke F8, und schwupp, ist das Programm weg. Immer nach exakt dem gleichen Satz 6.972. 6.973 läßt sich nicht anlegen.

Jan

ah, wer lesen kann ist klar im Vorteil.
Das kommt mir aber irgendwie bekannt vor. Ich meine sowas hatte ich auch schon mal.
rein zur Vorsicht, Index ist ok?
Schon mal versucht die besagte Menge an Leersätzen anzulegen, ob es dann auch knallt?

Hallo Jan,
es wird dir nur ein geringer Trost sein aber solche Abstürze erlebe ich immer wieder mal z.B. bei dbexport()
und es läßt sich nicht wirklich eruieren wo der Hund begraben ist ( vermutlich wohl in Xbase selbst )
Das einzige was bei mir ein wenig Abhilfe geschaffen hat war ein sleep(10) vor den Aufruf an zu stellen aber
zu 100% hat das auch nicht gewirkt.

Der Fehlercode bringt jedenfalls nie einen wirklichen Aufschluß, der ist mehr oder weniger bei fast dallen
Fatal-Abstürzen der gleiche - z.B. bekam ich den auch beim Ausdruck einer 8BPP-Grafik auf einem
Thermolinedrucker und da war die Ursache ein Speicherüberlauf am Drucker.

Lg, Marcel

du lässt dem CG zu wenig Zeit ...

ATM = Atom Manager (starts Garbage Collector?)
Separate Thread, may have different Thread ID in XppFatal.logs
* XppFatal Message: "Function: atmStartGCThread(void*)"
- Error Codes: "EH: 5"/"Sub: -1073741819(c0000005)"/"XPP: 41"

es kann helfen wenn du die Xbase++ "Optimierungen" wie setzt

Hallo Jimmy,

hilft nicht.

Jan

Jan hat geschrieben:hilft nicht.

du hast die DBF / Index NEU aufgebaut ?

Die wird IMMER vorher komplett neu aufgebaut. Und die Inzidee sind korrekt.

Jan

@Jan
Das ist ein Dateisystemfehler bei Win10

Goole mal unter '1073741819' - Eventuell hilft dir das weiter.

Gruß,
Bernhard

BIK hat geschrieben:Das ist ein Dateisystemfehler bei Win10

es handelt sich hier um XppFatal.LOG, also einer Fehlermeldung von Xbase++ und nicht vom Windows System.
genau der ATM Fehler wurde im Zitat erwähnt.

Error Codes: "EH: 5"/"Sub: -1073741819(c0000005)"/"XPP: 41"

@Jan
es ist anzunehmen das der CG "keine Zeit" findet ... SLEEP() könnte helfen.
nun findet das ganze wohl auch im Thread statt ... der braucht auch "seine Zeit"
jede geöffnete DBF "benötigt Zeit" ... alles schliessen was nicht gebraucht wird.

Frage : verwendest du DbRegisterClient() ?

Bernhard,

das kann hier nicht sein - der Laptop, auf dem ich da gearbeitet habe, hat noch Windows 7 drauf.

Jan

Jimmy,

Sleep hatte ich gestern acuh schon drni. Hat aber ebenfalls nichts gebracht.

Jan

Meine Vermutung es könnte etwas mit Win10 zu tun haben begründet sich aus der Tatsache dass ich auf einem älteren HP6830s der nach dem Upate auf Win10 eben dieser Fehler hatte.
Aufgrund einer sowieso anstehenden Neuanschaffung haben wir dieses Problem dann nicht mehr weiter verfolgt.
Ist der Fehler nur auf diesem Rechner oder kommt der auch an andereren Geräten zum vorschein?
Ich meine mich zu erinnern, dass wir auch den Speicher in Verdacht hatten. Wie viel Hauptspeicher hat der Laptop?

Gruß,
Bernhard

Ich denke, ich bin da einen Schritt weiter. Der Punkt ist, daß das eine recht große Datei ist, die ich importieren muß. Sowas ist extrem ungewöhnlich für emine Software. Der Kunde hatte die in UTF-8 vorliegen, hat die aber nach ANSI konvertiert (keine Ahnung, wie, ihc glaube mit einem normalen Editor). Und diese konvertierte Datei macht jetzt Probleme. Das könnte daher kommen, das der gute Mann aus Luxemburg kommt, die haben eine andere ANSI als wir hier.

Darauf gekommen bin ich, weil in der dbf merkwürdige Sonderzeichen stehen. Die im Original französische Buchstaben sind.

Und weil ich mir mal eine andere übergroße Musterdatei besorgt habe, die aus den USA kommt und damit für mich einen korrekten Zeichensatz beinhaltet. Damit klappt das nun wiederum einwandfrei.

Stellt sich mir nur die Frage: Warum zum Donnerwetter kann eine Datei mit einem nicht passenden ANSI-Zeichensatz alle DB-Fuktionen blockieren? Selbst ein DbCloseAll() führte zu einem sofortigen Absturz. Und in knapp der Hälfte aller Fälle ist das so massiv, das nicht mal eine xppfatal geschrieben werden konnte.

Jan

Bernhard,

das ist ein Windows 7 Ultimate 64 Bit mit 8 GB RAM. Wobei die zu importierende Datei 180 MB groß ist, die dbf nach dem Absturz ca. 14 MB groß ist. Also alles nicht weltbewegend.

Jan

Jan hat geschrieben: Stellt sich mir nur die Frage: Warum zum Donnerwetter kann eine Datei mit einem nicht passenden ANSI-Zeichensatz alle DB-Fuktionen blockieren? Selbst ein DbCloseAll() führte zu einem sofortigen Absturz. Und in knapp der Hälfte aller Fälle ist das so massiv, das nicht mal eine xppfatal geschrieben werden konnte.
Jan

Das heisst, wenn du die Zeichen mit STRTRAN raus nimmst läuft das Programm?

Bernhard,

nein. Es läuft, wenn ich eine komplett andere Datei nehme mit US-Zeichensatz, aber mit einer ähnlichen Größe (Original ca. 9,3 Mio. Zeilen, US-Datei ca. 7,8 Mio. Zeilen).

Ich habe aber bei meinem Kunden seine Datei im Original, also in UTF-8, angefordert. Die werde ich dann mal selber konvertieren und schauen, was dann dabei heraus kommt.

Jan

Na super.

Ich habe jetzt die Original-Datei von eminem Kunden. Und konvertere die während des Importes selber nach ANSI. Und trotzdem stirbt der immer noch an exakt der gleichen Stelle.

Einziger Unterschied: In der dbf stehen jetzt die korrekten französischen Buchstaben, nicht mehr diese seltsamen Ersetzungen.

Da muß in dieser Datei also noch irgend was anderes drin sein, was stört.

Seltsam ist einfach nur: Im ersten Durchlauf komme ich genau bis Datenatz 6.972. Lasse ich den Import dann noch einmal auf die gleiche dbf laufen, dann stirbt der nicht nach Satz (6.972 * 2) = 13.944, sondern erst in 66.482.

Jan

Dann würde ich mal mit einem Hex-Editor schauen, was an der Stelle für Zeichen stehen.
Du verarbeitest einen 180MB großen String im Speicher ?
Eventuell direkt aus einer Datei Satzweise( wie Du es benötigst) einlesen

Hallo,

inzwischen bin ich einen Schritt weiter. Zur Info: Die eingelesene Datei ist eine reine Textdatei, in der nach einer festen Struktur Kennzeichen für ede Zeile eingebaut sind die angeben, wie der Text in dieser Zeile zu bewerten ist. Anhand dieser Kennzeichen werte ich die Daten aus und schreibe sie in die verschiedenen Felder meiner dbf.

Ich bin gerade dabei, das Schritt für Schritt aufzubohren. Im ersten Durchlauf habe ich alles auskommentiert, was nicht zur eindeutigen Identifizierung notwendig ist. Das ist sauber durch alle Zeilen durchgelaufen. Zur Zeit läuft der nächste Versuch, in dem ich ca. die Hälfte aller Kennzeichen freigegeben habe. Der sieht ebenfalls seht gut aus, ich bin da schon bei ca. der Hälfte der Zeilen durch. Was ich in der Vollversion nie geschafft habe, da war immer schon nach 2 oder 3 % Schluß.

Ich taste mich da also Scheibchenweise ran. Und hoffe so, den auslösenden "Fehler" identifizieren zu können.

Mich irritiert aber immer noch, warum ein Fehler in einer Textdatei eine dbf zum Totalabsturz bringen kann. Total irre!

Jan

Hallo Klaus,

das Einlesen der großen Datei dürfte nicht das Problem sein. Ich hatte ja den Test mit der US-Datei gemacht, die war fast genau so groß, und die lief sauber durch.

Der Hex-Editor hilft mir ja leider nicht. Denn die Daten für den dbf-Satz vor dem Absturz werden noch korrekt ausgelesen. Oder naja, vielleicht auch nicht. Denn wenn schon ein DbCloseArea() nach diesem Satz das Programm ohne xppfatal abstürzen lassen, dann muß sich da schon ganz schön was wild verknotet haben.

Jan

Jan,

das Einlesen selbst nicht. Aber die Weiterverarbeitung. Ich meine wir hätten das Thema Speicher / Abstürze schon mal
mit Riesenstrings und substr.

Ich lese mit meinen Importroutinen 350 MB Dateien ein, die auf 600.000 Sätze verteilt werden ... es sollte also gehen.
XPPFATAL sogar mit Fehlerfunktion, das würde ich an Alaska melden mit Beispiel !
Die baust die Indexe vorher auf ... wenn du den Index in der Zieldatei nicht beim Import benötigtst, würde ich einlesen ohne index und danach neu aufbauen.

Jan hat geschrieben:Und konvertere die während des Importes selber nach ANSI.

du könntest testweise erst den Import machen und wenn der durchläuft dann die Konvertierung.
du könntest die Import Routine mal "auskoppeln" und als kleines Stand-Alone testen ob es einen Unterschied macht.