Parameter verschwinden in Function [ERLEDIGT]

[Manfred]

Irrtum, wieder was dazugelernt. Es gab ein BREAK und dann springt das Programm auf das Recover. Hm, hatte ich bisher nie genutzt deshalb bin ich jetzt auch darauf reingefallen. Da es etliche breaks gibt, scheint es wohl nicht die erste Wahl zu sein ein Recover einzubauen !?

[Tom]

Hallo, Manfred.

Wahrscheinlich einen versteckten Fehler. Wobei sich in diesem Zusammenhang die durchaus interessante Frage auftut, wie die Errorsys aussieht. Gibt es überhaupt eine funktionierende Laufzeitbehandlung? Was passiert eigentlich, wenn Du einen Fehler forcierst, also zum Beispiel eine DBF durch eine TXT-Datei ersetzt wird?

[Manfred]

es gibt eine Errorsys zu dem System und die klappt auch. Es endet ja auch in diesem Fall in der selben allerdings durch einen Folgefehler. Der eigentlich Fehler, wenn ich ihn mal so nennen darf, der ist nicht zu lokalisieren. Langsam kriege ich die Pimpernellen.

[satmax]

Irrtum, wieder was dazugelernt. Es gab ein BREAK und dann springt das Programm auf das Recover. Hm, hatte ich bisher nie genutzt deshalb bin ich jetzt auch darauf reingefallen. Da es etliche breaks gibt, scheint es wohl nicht die erste Wahl zu sein ein Recover einzubauen !?

Mach einfach

Code: Alles auswählen

Do While   // War Begin S
   Exit       // War Break
ENDDO     // War  END S

daraus

[Manfred]

Nee, geht nicht. Es kann sein, dass in einem Unterprogramm ein Break steht und das würde dann nichts mehr bringen. Das muß ich alles noch prüfen und umbauen im Fall des Falles.

[satmax]

In einem Unterprogramm mit einem Break herausspringen...

dann verwende zumindest Huberts DebugPrint(), für mich unverzichtbarer wie der Debugger selbst. Damit musst den Fehler in relativ kurzer Zeit haben.

[Manfred]

ja, das Programm ist komplett auf Begin Sequence ausgelegt. Jede Function hat das.

Meinst Du DebugPrint() von Hubert das mit Set Alternate? Das baue ich gerade ein, hat aber bisher keinen Erfolg gebracht. Es sind unheimlich viele Stellen, wo ich das unterbringen muß, bzw. ich muß erstmal suchen, wo das überhaupt wirkt und nicht schon abkackt, weil eben Werte nicht vorhanden sind.

[Tom]

Oder Rogers DC_Debug in seinen zig Varianten.

Das BREAK soll ja die Aufgabe eines RETURNs übernehmen. Aber auch ein Return haut man nicht so einfach in den Code, wenn man meint, hier könne es irgendwie zuende sein. Man muss Tabellen schließen, Objekte aufräumen, Zustände restaurieren, wasweißich. Jedenfalls sind unkonkrete Abbruchbedingungen nicht die feine Art, also einfach etwas so lange zu machen, bis irgendein Zustand eintritt. Und erst recht nicht in Sequenzen. Aus DO WHILEs kann man schon mal rausspringen, aber auch das sollte gut vorbereitet passieren.

Und wenn es dann auch noch RECOVER-Anweisungen gibt und ersetzte Fehlercodeblöcke, dann ist davon auszugehen, dass der ehemalige Programmiere wusste, dass das in bestimmen Situationen scheitern konnte. In diesem Fall einfach so zu tun, als wäre alles fein, und darauf zu hoffen, dass es keine (bemerkten) inhaltlichen Fehler gibt, das ist schlicht Spaghettiprogrammierung.

Andererseits sieht der Code an anderen Stellen nicht eben unelegant aus. Oder ist das bereits Deine Revision, Manfred?

[Tom]

Genau. Link doch einfach mal eXpress++ ran, das geht ja ohne Aufwand (DCDIALOG.CH includen und #PRAGMA für die DCLIPX.DLL). Mit dem WTF-Kommando kannst Du da schön Inhalte und Callstacks überwachen.

[Manfred]

also Recover gibt es eigentlich nicht. Und die breaks sind schon abgestimmt.

Das mit express++ hätte ich auch selbst beachten können. Sowas blödes.

[Manfred]

ich habe jetzt zwar die Stelle gefunden, an der es zu passieren scheint, aber eingrenzen kann man es nicht.

[Manfred]

es ist nicht nachvollziehbar. Die Funktionen werden mehrmals aufgerufen und fehlerfrei abgearbeitet. Ab einer bestimmten Anzahl knallt es. Mal eine Zeile vorher, mal eine nachher. Sobald ich im Debugger irgendeine Aktion durchführe z.B. Einzelschritt passiert es früher, oder an anderer Stelle. Lasse ich es über einen breakpoint laufen, der erst bei einer bestimmten Voraussetzung stoppt, sind die Vars bis dahin belegt und sobald ich einen Step mache, sind sie "leer". So stelle ich mir einen gelungenen Wochenendanfang vor.

Naja, wenigstens scheint die Sonne

[AUGE_OHR]

ich habe mal Memwatch mitlaufen lassen nur mal so. Kann jemand mit dem Logfile was anfangen?
...
das ist jetzt bis zur Fehlermeldung

das mit den Handles ist mir auch aufgefallen. da es extrem ansteigt gehe ich davon aus das ein (grosses) Array im Spiel sein muss, oder ?

wenn Array : wie wird es erstellt ?
wird es "im Stück" definiert oder per AADD() hinzugefügt ?

[Manfred]

so einen xppfatal habe ich gerade erzeugt

FATAL ERROR LOG
System-Error
SYS Thread-ID: 824
Module: MOM
Error Codes: EH: 4 Sub: 5(5) OS: 5 XPP: 40
Call Stack of Thread 1 (604):
STANDARDEH(72)
(B)ERRORSYS@0000(58)
NIM_FLAARC(1542)
VORTRAG_BILANZ(801)
ALLE_ABS_NEU(276)
ABS_TGSELECT(232)
(B)abs_tues(63)
MOD_WINDOW(1132)
ABS_TUES(63)
(B)LAD_AR_AKTION@0016(706)
AL_PROMPT_AKTION(911)
MAIN(583)
Call Stack of GUI Thread (824):
File: v:\vt_restore\vt\VT_32_02_20150301.exe
TimeStamp: 20150822 18:25
End of FATAL ERROR LOG.

[AUGE_OHR]

Module: MOM
Error Codes: EH: 4 Sub: 5(5) OS: 5 XPP: 40

MOM = Memory Object Manager

EH : 4 // "Operating system error"

Sub : 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"

OS : 5 ERROR_ACCESS_DENIED Access is denied.

XPP : 40 XPP_ERR_DOS Operating system error: occurs if the
error cannot be identified more
precisely.

Frage : verwendest du (grosse) Arrays ?

[Jan]

Ich glaube nicht, das es an großen Arrays liegt. Ich habe zwei verschiedene Situationen durchgemacht mit großen Arrays:

• Das Array zu groß erstellen. Ergibt eine komplett irreführende Fehelrmeldung.
• Einen Satz zu viel angehängt. Das Programm stürzt ohne jede Fehlermeldung komplett ab.

Bei dieser xppfatal tippe ich eher darauf, das irgendwelche Bereiche voll laufen. Das Ansteigen der Handles und des verbrauchten Speichers aus dem Memwatch-Protokoll weist auch in die Richtung. Irgendwo wird was nicht sauber aufgeräumt, und Xbase++ streicht dabei irgendwo die Segel.

Aber um das auszuschließen: Es gibt einen Patch von Alaska, mit dem man mehr Speicher für Arrays freigeben kann. Was nicht hilft bei einer initialen Erzeugung eines zu großen Arrays. Ist der String zu lang, knallt es. Aber ein Adden geht damit sehr gut, auch ohne die von Alaska propagierten Performance-Nachteile.

Jan

[Manfred]

also mit dem DCBDBUG von Roger komme ich auch nicht weiter. Es werden ja nur die Werte angezeigt, die ich übergebe!? Die sind aber in ordnung, ich müßte alle Werte sehen um zu beurteilen, welche aus dem Rahmen fallen.
Zu große Arrays kann ich nicht entdecken und es wird alles wieder genillt, oder geleert, wenn die Routinen verlassen werden.

[georg]

Hallo, Manfred -


es kam auch der Hinweis, dass ein Sleep(1) helfen könnte. Vielleicht habe ich's im Umfang dieses Themas übersehen: hast Du das mal versucht?

[Manfred]

Hi Georg,

bringt überhaupt nichts.

[AUGE_OHR]

Zu große Arrays kann ich nicht entdecken und es wird alles wieder genillt, oder geleert, wenn die Routinen verlassen werden.

das meinst du ...

wenn man den Sprung bei den Handles ansiehst fragt sich doch "was" überhaupt 10000 Handles "fressen" könnte ... das geht IMHO nur mit einem (grossen) Array !

Frage : wird das Array "im Stück" oder per AADD() erstellt und wie gross ist es ca. ?

ich nehme mal an das es eine LOCAL Variabel ist ... schon mal eine STATIC ausprobiert ?

[Werner_Bayern]

Zu große Arrays kann ich nicht entdecken und es wird alles wieder genillt, oder geleert, wenn die Routinen verlassen werden.

Aber vermutlich nicht bei einem BREAK oder einem Fehler, wo er an end sequence springt?

[Martin Altmann]

Guter Hinweis, Werner. Müsste Manfred mal schauen, an welcher Stelle er NILed.
Manfred, auf jeden Fall nicht bei einer Rekursion

Viele Grüße,
Martin

[Jan]

und es wird alles wieder genillt, oder geleert, wenn die Routinen verlassen werden.

Moin Manfred,

es wiederstrebt mir Dir zu widersprechen. Aber das kann nicht stimmen, denn sonst würden die Handles nicht so in die Höhe gehen, und der verfügbare Speicher abnehmen. Irgendwas wird da wieder und wieder erzeugt. Oder es wird zwar zerstört, dem GC wird aber keine Zeit zum Aufräumen gegeben.

Jan

[satmax]

ABS_TUES() ist 2x in deinem Callstack.

[Manfred]

OK,

das Nillen habe ich erst nachträglich eingebaut um zu prüfen, ob es daran liegen könnte. Hatten wir ja schonmal, das der GC nicht mehr nach kam. Aber es geht hier m.E. nicht um die Mengen Datensätze wie damals. Es wird auch immer und nur am Ende der jeweiligen Funktion gemacht und das bei den Local Variablen

Wenn ich die Durchläufe an einem Stück mache, dann tritt der Fehler immer an der gleichen Stelle auf. Es hat aber nichts mit den Daten zu tun, die zu der Zeit abgearbeitet werden. Die Vermutung hatte ich auch schon. Denn wenn ich das in Blöcke unterteile, bleibt es bei der Menge der Durchläufe sie verschieben sich nur. Wenn ich die Durchläufe unterteile in Blöcke, die genau 1 weniger haben als der Fehler benötigt, dann gibt es trotzdem wieder einen Fehler wenn die Gesamtzahl erreicht wird. D.h. bei 8 Duchläufen knallt es, bei 7 nicht. Also mache ich einen Block von 7 und warte dann bis ich den nächsten 7er Block starte (das sollte für den GC reichen was zu unternehmen). Dann knallt es aber schon beim 1-3 Durchlauf. Wenn ich aber einen 7er Block starte, das Programm beende und dann den nächsten 7er Block starte, dann läuft der durch.

Es hat alles mal geklappt. Es gab nur zwischendurch einmal eine Umstellung von NTX auf CDX. Ob ich da irgendwas angestossen habe? Keine Ahnung. Ich baue mir gerade wochenweise die Quellcodezustände wieder auf und prüfe jetzt Schritt für Schritt, ab wann der Fehler auftrat. Es kann sich also nur um Stunden handeln, bis ich der Sache näher auf die Schliche komme.
Hat aber auch seinen Vorteil, ich habe noch ein paar Verbesserungsmöglichkeiten für meine Datensicherungen entdeckt dabei...