Interne Datenstrukturen beschädigt - Grund?

Alle Fragen um die Programmierung, die sich sonst nicht kategorisieren lassen. Von Makro bis Codeblock, von IF bis ENDIF

Moderator: Moderatoren

Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Interne Datenstrukturen beschädigt - Grund?

Beitrag von Tom »

kaputter Index macht auch diesen Error
Oder: "Unzulässige Funktion".
Herzlich,
Tom
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Interne Datenstrukturen beschädigt - Grund?

Beitrag von AUGE_OHR »

Daniel hat geschrieben:
Tom hat geschrieben:Remarks: Also in Fatal Error Logs: "EH: 5"/"OS: 0"/"XPP: 41",
"Function: atmStartGCThread(void*)", "Module: ATM"[/i]
Danke, sind damit die obigen Angaben aus dem Errorlog gemeint: oError: gencode : 41, subcode : 5 ?
JA
GenCode:
41 XPP_ERR_CORRUPTION Internal data structures corrupted (an
unexpected OS error occurred or corrupted XPF file)

SubCode :
0005 - [BASE] - ???
Associated with: "41:Internal data structures corrupted"
Caused by: Various things, including: "Memory(0)", ":UpdateBuffer()",
"AppEvent()", "ValType()", etc.
Remarks: Also in Fatal Error Logs: "EH: 5"/"OS: 0"/"XPP: 41",
"Function: atmStartGCThread(void*)", "Module: ATM"
Die Stelle in MAIN(345) steht im RECOVER einer SEQUENCE innerhalb einer MENU-Iteration:

Code: Alles auswählen

(345) set printer off    ;    set printer to
ich war schon letzte Mal über die Stelle gestolpert wusste aber nicht das es mit MENU zu tun hat ...
Error: operation : set
...
Aufgerufen von MAIN(345)
Frage : warum hast du die Zeile 345 dort stehen ? ist ein "Printer" (Object) zu dem Zeitpunkt aktive ?
( und nimm mal das ";" aus der Zeile 345 damit man sehen kann welches SET er meint )

wenn du dir nicht sicher bist könntest du vielleicht

Code: Alles auswählen

lOldPrint := SET(_SET_PRINTER)
clOldFile := SET(_SET_PRINTFILE)
...
SET(_SET_PRINTER, lOldPrint)
SET(_SET_PRINTFILE, cOldFile)
verwenden.
gruss by OHR
Jimmy
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Interne Datenstrukturen beschädigt - Grund?

Beitrag von Tom »

und nimm mal das ";" aus der Zeile 345 damit man sehen kann welches SET er meint
Ich würde das in zwei Zeilen zerlegen, denn es sind ja zwei. Und/oder mal ein PRG mit nur dieser Zeile durch den Präprozessor jagen, um zu sehen, was der eigentlich daraus macht:

Code: Alles auswählen

Set( 23, "OFF" );Set( 24, "" )
Das sollte schon funktionieren, aber erhellender wäre das tatsächlich in zwei Zeilen.
Herzlich,
Tom
Daniel

Re: Interne Datenstrukturen beschädigt - Grund?

Beitrag von Daniel »

Es geht an dieser Stelle, wo man aus den Menupunkten des Hauptmenues zurückkommt,
einfach darum, alles zu beenden oder zu schliessen, was allenfalls noch offen oder übrig geblieben sein "könnte".
Klar, wie erwähnt, es ist ein älteres Prg, und in dem Moment, wo da ein Error auftaucht,
muss man solche Dinge ändern, wie 2 Befehle auf 1 Zeile.
Wie ebenfalls erwähnt, gab es früher mit diesen Dingen nie Probleme.
- Und möglicherweise lag das eigentliche Problem woanders (?) - Indexproblem? ...

Nun stellt sich die Frage: welche Strategie einschlagen?
Erst mal, wie Tom schrieb, allfällige noch offene Dateien anhand der WorkSpaceList schliessen (ev. vorher noch Filter aufheben? Relationen +Scopes sind nicht verwendet)?
Dann die "SET"-Zustände erst abfragen, dann allenfalls auf "Normalzustand" zurücksetzen?

Wie kann man eigentlich einen Speicherfehler feststellen? Jimmy schrieb im oben erwähnten Thread (von 2008):
... hatte einen "alten" PC ... ... Ich hab also auf die Netzwerk Karte getippt und 3x ausgetauscht ... nix.
Zum Schluss hab ich den RAM Riegel wieder rausgenommen und siehe da: der PC läuft ohne Probleme...
RAM wurde übrigens immer mit MEMTEST v1.86+ getestet und ist ok !
Es fällt mir auf, dass die Errors immer nur bei Win XP-Workstations auftreten ...

Aber wer weiss, ob der Error überhaupt jemals wieder auftritt, wenn ich das alles (nicht) erweitere?
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Interne Datenstrukturen beschädigt - Grund?

Beitrag von AUGE_OHR »

Daniel hat geschrieben:Wie kann man eigentlich einen Speicherfehler feststellen? Jimmy schrieb im oben erwähnten Thread (von 2008):
wie ich schon schrieb testet MEMTEST v1.86+ den RAM Speicher aber leider sagt es nichts darüber aus ob Applikationen dann fehlerfrei laufen.
Daniel hat geschrieben:Es fällt mir auf, dass die Errors immer nur bei Win XP-Workstations auftreten ...
hat der PC noch eine parallele Schnittstelle bzw. läuft da der Drucker ?
wenn ja ist es evtl. ein "Multi-Funktion" (Drucker/Scanner/Fax) mit "gewaltiger" Software (Treiber) ?
Daniel hat geschrieben:Aber wer weiss, ob der Error überhaupt jemals wieder auftritt, wenn ich das alles (nicht) erweitere?
einen Drucker "an/aus" zu schalten sollte sich doch auf die entsprechenden Routinen beschränken was man eingrenzen kann (suchen nach "set printer").
gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Interne Datenstrukturen beschädigt - Grund?

Beitrag von brandelh »

Ich frage vor einem CLOSE stets ab ob (nSelect)->(used()) ist.

Code: Alles auswählen

if (nSelect)->(used())
   (nSelect)->(DbCloseArea())   
endif
Ich vermute, dass ein interner Zeiger verstellt wird und auf einen Speicherbereich zeigt wo er nichts zu suchen hat.
Das kann Code sein oder aber auch Variablen (locals) vermutlich ist eine Verbindung wegestorben ohne dass die Referenzen das mitbekommen haben.
Aber wie geschrieben, das ist nur eine Vermutung. "Internal Errors" sind auf jeden Fall von der Art, dass Xbase++ sie nicht abfangen kann.
Das ist der Unterschied zu "normalen" Runtime-Errors, fehlende Disketten, volle Laufwerke, fehlende Dateien, damit kann Xbase++ umgehen und sendet diese in die ErrorSys() ...
oder man kümmert sich selbst in einem SEQUENCE Block. Das meinte ich damit, dass diese Fehlermeldung eigentlich nicht auftauchen sollte.

Möglicherweise haben die Korrupten Indexe und die Häufung dieses Fehlers auch etwas mit Fehlern im OS zu tun, M$ mag keine gesharten Dateien ;-)
Gruß
Hubert
Daniel

Re: Interne Datenstrukturen beschädigt - Grund?

Beitrag von Daniel »

AUGE_OHR hat geschrieben:hat der PC noch eine parallele Schnittstelle bzw. läuft da der Drucker ?
wenn ja ist es evtl. ein "Multi-Funktion" (Drucker/Scanner/Fax) mit "gewaltiger" Software (Treiber) ?
Möglicherweise gibt es noch XP-Workstations mit paralleler Schnittstelle, meist aber musste "LPT1" (lokal) und "LPT2" (Netzdrucker) mit "NET USE" (CMD) umgeleitet werden, bis das Programm angepasst ist. Der "Multi-Funktion" ist aber an der Win7-WS.
- Aber der Verdacht bleibt, dass es ev. der Speicher sein könnte. Habe mal den 'Computername' ins ErrorLog eingebaut.
einen Drucker "an/aus" zu schalten sollte sich doch auf die entsprechenden Routinen beschränken, was man eingrenzen kann (suchen nach "set printer").
Wie erwähnt organisiert jedes Unterprogramm im Hauptmenu alles unabhängig, also Dateien öffnen, sperren, schreiben, unlock, Drucker ein / aus, und am Ende (meist) COMMIT und CLOSE DATABASES.
Die Schluss-Befehle in SEQUENCE / RECOVER und nach ENDDO WHILE (Menu-Ende) dienen nur zum "aufräumen", dh. den "sauberen" Zustand wiederherzustellen.
Ich nehme an, man sollte / müsste heute zuerst prüfen, ob es da überhaupt eine Druckausgabe auszuschalten oder eine Datei zu schliessen gibt. Bei Clipper machte man einfach ein CLOSE DATABASES / CLOSE ALL und dachte, damit ist alles geregelt. Steffen Pirsig sagte auch mal, bei einem CLOSE, resp. DbCloseArea() wird UNLOCK und COMMIT automatisch gemacht - aber das scheint, wenn man hier im Forum alle möglichen Erfahrungen liest, doch nicht ganz so sicher zu sein. :?:
Im Standard-ErrorSys (STATIC PROC ErrorLog) wird es allerdings auch einfach mit SET PRINTER OFF und SET CONSOLE ON gelöst (gefolgt von der Abfrage von SetAppWindow() ).
Daniel

Re: Interne Datenstrukturen beschädigt - Grund?

Beitrag von Daniel »

brandelh hat geschrieben:Ich frage vor einem CLOSE stets ab ob (nSelect)->(used()) ist.
Das wäre wohl in einer "Aufräum-Function" auch mit der Abfrage der WorkSpaceList() erfüllt, richtig?
Ist es das, was Jimmy mit "WSL-CLOSE" gemeint hat / hast? (- vgl. SAMPLE AppExit() )
... ein interner Zeiger verstellt wird und auf einen Speicherbereich zeigt wo er nichts zu suchen hat.
Das kann Code sein oder aber auch Variablen (locals) vermutlich ist eine Verbindung wegestorben ohne dass die Referenzen das mitbekommen haben.
Ein grösseres Problem sind wahrscheinlich in einer älteren Applikation wie dieser die unzähligen verstreuten PRIVATE Variablen, die ja an alle Folge-PROCs weitergegeben werden, aber auch wieder neu gesetzt werden können. (Und nur nebenbei noch die Möglichkeit bei Clipper, den Typ von Variablen zu ändern - die ja bekanntlich dazu führt, dass sich Leute, die PASCAL o.ä. gelernt haben, mit Grausen von XBase++ abwenden :wink: - setze ich natürlich nie ein).
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Interne Datenstrukturen beschädigt - Grund?

Beitrag von brandelh »

Nein, die Funktion WorkSpaceList( [<nWorkSpace>] ) dient dazu, DBF-select Bereiche von einem Thread an einen anderen weiterzugeben.
Sowas mache ich nicht.

Ich merke mir ein einem Array je Fenster für alle von diesem geöffneten Dateien die Selectbereiche.
Am Ende müssen alle wieder geschlossen werden, sicherheitshalber wird dort dann die Abfrage auf used() gestellt, bevor dbCloseArea() dafür aufgerufen wird,
da es ja sein könne, dass eine vorher schon geschlossen wurde. Das soll Laufzeitfehler abfangen.

CLOSE ALL oder CLOSE DATABASES sollte eigentlich nur offene Dateien schließen, aber offensichtlich kommt es ab und an zu fehlern.
Ein Durchlauf durch alle Selectbereiche (1 bis 255 ?) oder durch die die ich selbst gemerkt habe (im Array) mit der Sicherungsabfrage auf USED() macht das Gleiche wie CLOSE DATABASES aber auf einem anderen Weg.
Ein anderer Weg könnte aber einen BUG in Xbase++ umgehen wenn so andere Routinen aufgerufen werden.
Gruß
Hubert
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Interne Datenstrukturen beschädigt - Grund?

Beitrag von AUGE_OHR »

brandelh hat geschrieben:Nein, die Funktion WorkSpaceList( [<nWorkSpace>] ) dient dazu, DBF-select Bereiche von einem Thread an einen anderen weiterzugeben.
siehe dir doch bitte mal c:\ALASKA\XPPW32\Source\SYS\AppExit.prg an wie man die WorkSpaceList() statt CLOSE DATABASE verwenden kann.
gruss by OHR
Jimmy
Daniel

Re: Interne Datenstrukturen beschädigt - Grund?

Beitrag von Daniel »

AUGE_OHR hat geschrieben:siehe dir doch bitte mal c:\ALASKA\XPPW32\Source\SYS\AppExit.prg an, wie man die WorkSpaceList() statt CLOSE DATABASE verwenden kann.
Ja, das meinte ich - hast du auch das gemeint mit dem "WSL_CLOSE"?
Das habe ich jetzt genommen und ein wenig angepasst.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Interne Datenstrukturen beschädigt - Grund?

Beitrag von AUGE_OHR »

Daniel hat geschrieben:Ja, das meinte ich - hast du auch das gemeint mit dem "WSL_CLOSE"?
Das habe ich jetzt genommen und ein wenig angepasst.
YUP , damit bekommst du "wenn" es knallt zumindest raus bei welcher DBF er Probleme hatte.
Im Standard-ErrorSys (STATIC PROC ErrorLog) wird es allerdings auch einfach mit SET PRINTER OFF und SET CONSOLE ON gelöst (gefolgt von der Abfrage von SetAppWindow() ).
was, in deinem Fall, auch dein rekursiver Fehler sein "könnte" ...

wenn ich dich richtig verstanden habe passiert das alles im XbpMenu() System ?
wenn ja würde ich mal versuchen all die "Befehle" in eine Function zu verschieben und die Function aufrufen.
... ich bin mir nicht sicher in welchen Thread ein XbpMenu() läuft
gruss by OHR
Jimmy
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Re: Interne Datenstrukturen beschädigt - Grund?

Beitrag von Werner_Bayern »

Servus Daniel,

nutzt Du da Threads für die jeweiligen Programmteile, die Du über das Menüsystem startest?
es grüßt

Werner

<when the music is over, turn off the lights!>
Daniel

Re: Interne Datenstrukturen beschädigt - Grund?

Beitrag von Daniel »

AUGE_OHR hat geschrieben:YUP , damit bekommst du "wenn" es knallt zumindest raus bei welcher DBF er Probleme hatte.
Ich hoffe es - falls er das Array-Item mit meldet ...
... auch einfach mit SET PRINTER OFF und SET CONSOLE ON gelöst (gefolgt von der Abfrage von SetAppWindow() ).
was, in deinem Fall, auch dein rekursiver Fehler sein "könnte" ...
Ja, das ist möglich. Bei SET PRINTER ist allerdings die Abfrage etwas komplizierter, da man " _SET_PRINTER" und "_SET_PRINTFILE" auseinander halten muss ...
wenn ich dich richtig verstanden habe passiert das alles im XbpMenu() System ?
Nein, das ist auch ein altes Clipper-Menu mit DO WHILE und SEQUENCE.
Daniel

Re: Interne Datenstrukturen beschädigt - Grund?

Beitrag von Daniel »

Werner_Bayern hat geschrieben:Servus Daniel,
nutzt Du da Threads für die jeweiligen Programmteile, die Du über das Menüsystem startest?
Hallo Werner

nein, keine Threads, war alles noch wie Clipper "zu Fuss"...

- Habe erst mal eben diese "WSL_CLOSE" anhand der genannten "AppExit" gemacht,
und bei den SET-Befehlen aufgeräumt, d.h. nur noch die wirklich wichtigen stehen gelassen.
Ueberlege jetzt, ob ich bei denen allen zuerst die Zustände abfragen soll / müsste.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Interne Datenstrukturen beschädigt - Grund?

Beitrag von AUGE_OHR »

Daniel hat geschrieben:
AUGE_OHR hat geschrieben:YUP , damit bekommst du "wenn" es knallt zumindest raus bei welcher DBF er Probleme hatte.
Ich hoffe es - falls er das Array-Item mit meldet ...
du kannst ja das WSL mit SELECT(i) modifizieren und in der Errorsys SELECT() bzw. ALIAS() abfragen und aus der WorkSpaceList() das Element nehmen.
gruss by OHR
Jimmy
Daniel

Re: Interne Datenstrukturen beschädigt - Grund?

Beitrag von Daniel »

AUGE_OHR hat geschrieben:du kannst ja das WSL mit SELECT(i) modifizieren und in der Errorsys SELECT() bzw. ALIAS() abfragen und aus der WorkSpaceList() das Element nehmen.
ja, danke Jimmy, das ist eine gute Idee.
Man müsste das aber so machen, dass es möglichst in jedem Fall die aktuelle DBF angibt.
Antworten