Hartnäckiger Fehler

[Ewald]

Guten Tag zusammen,
ich bin auf der Suche nach einer Fehlerursache, die wochenlang trotz intensiver Nutzung nicht auftritt und dann plötzlich wieder zuschlägt.
Es geht um zwei verschiedenen xbase Anwendungen (zwei selbständige exe), die gleichzeitig laufen. Sie haben nichts miteinander zu tun.
In beiden Programmen werden Daten erfasst.
Ab und zu passiert nun folgendes.
Wenn der User während der Erfassung von einem Programm in das andere Programm wechselt um dort was zu erledigen und dann in das erste Fenster zurück klickt, knallt Programm eins in unregelmäßigen Abständen mit einer Fehlermeldung ab. An dieser Stelle ist im Quellcode von if::isCalc die Rede.
Das Verfluchte an dieser Sache ist, man kann sofort anschließend versuchen, mit exakt der gleichen Vorgehensweise den Fehler nachzuvollziehen bzw. zu provozieren. Es gelingt nicht. Da es sich um zwei vollkommen unabhängige Programme handelt bin ich der Meinung, das sie sich auch nicht beeinflussen können. Ich habe aber auch nicht die geringste Vorstellung, warum isCalc alle paar Wochen einen falschen Datentyp hat . Das ganze passiert in einer Netzwerkumgebung mit 4 gleichen Arbeitsstationen immer nur beim gleichen User am gleichen PC. Kann durchaus sein, das nur dieser User die Gabe hat, das Problem durch ausgeklügelte Vorgehensweise auszulösen.
Kann mir da jemand weiterhelfen und sagen, wo ich den Hebel ansetzten muss um die Ursache zu finden und abzustellen ?

• ------------------------------------------------------------------------------
  ERROR LOG of "O:\HOSPERFA.EXE" Date: 24.03.2014 14:20:53
  
  Xbase++ version : Xbase++ (R) Version 1.90.331
  Operating system : 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 : Parameter has a wrong data type
  oError:filename :
  oError:genCode : 2
  oError:operation :
  oError:osCode : 0
  oError:severity : 2
  oError:subCode : 2311
  oError:subSystem : BASE
  oError:thread : 1
  oError:tries : 0
  ------------------------------------------------------------------------------
  CALLSTACK:
  ------------------------------------------------------------------------------
  Called from DC_XBPGET:HOME(1574)
  Called from DC_XBPGET:_ASSIGN(1103)
  Called from DC_XBPGET:SETDATA(770)
  Called from DC_GETVALIDATE(8447)
  Called from _PROCESSHOTKEY(5314)
  Called from DC_GETLIST:EVENTLOOP(4625)
  Called from DC_GETLIST:READGUI(3677)
  Called from DC_READGUI(101)
  Called from MAIN(140)

[Tom]

Wie sieht der Code für das betroffene DC(SAY )GET aus? Verwendest Du dort die Option "CALCULATOR"?

Der Fehler tritt in _DCXBPGT.PRG auf, in der Methode DC_XbpGet:SetData(). Dort wird die iVar "isCalc" abgefragt, die beim Create() gemäß Optionen für das DCGET gesetzt wird.

Du hast allerdings, wenn ich das richtig sehe, eine ältere eXpress++-Version. Hast Du mal in Rogers Forum in den Readmes für die neueren Versionen geschaut, ob dort ein Fehler bezogen auf die CALCULATOR-Option korrigiert ist?

[Ewald]

Hi Tom,
schön was von dir zu hören. Auch wenn der Anlass mal wieder nicht so prall ist.
Der Calculator spielt in diesem Zusammenhang keine Rolle.
Der User steht im Fenster eins in einem Browse. Ich werde mal genauer. In der Tabelle werden Name, Vorname, Geb etc. erfasst. Mit "enter" springt man von Feld zu Feld.
Wenn es passiert hat der User Name und Vorname eingegeben und der Eingabefocus steht im Feld "geboren". Es gibt keine valid oder dergl.
Dann wechselt er in die zweite Anwendung und klickt sich irgendwann zurück.
Wenn nichts passiert steht die Eingabe immer noch im Feld geboren (allerdings nicht aktiviert). Wenn doch was passiert siehe Fehlermeldung oben ...
Wie gesagt, 1000mal geht es gut dann mal wieder nicht.

Code: Alles auswählen

dcbrowsecol field erfatabe->name       header "Nachname"   parent ob1 ;
                                     picture "@!" width 30 font "10.Arial" ;
                                     object fangan

dcbrowsecol field erfatabe->vorname    header "Vorname"    parent ob1 ;
                                     picture "@!" width 30 font "10.Arial"

dcbrowsecol field erfatabe->geb        header "geboren"    parent ob1 ;
                                     width 6  font "10.Arial"

dcbrowsecol field erfatabe->behandlung header "Behandlung" parent ob1 ;
                                     width 6  font "10.Arial" 

dcbrowsecol field erfatabe->nummer     header "Nummer"     parent ob1 ;
                                     width 08 protect {||.t.} ;
                                     font "10.Arial" picture "@R 99-99-999999"

@ 37,01 dcpushbutton caption "Ende " size 10,1 ;
        action {||fsicher(getlist),dc_readguievent(DCGUI_EXIT_OK,Getlist)}

@ 37,12 dcpushbutton caption "Einspielen" size 10,1 ;
        action {||fabuchen(getlist)} 

@ 37,53 dcpushbutton caption "RESET" size 10,1 ;
        action {||freset(getlist)} 

dcread gui fit ;
options getoptions ;
title "Akten erfassen" ;
eval {|o|setappwindow(o)}

[Tom]

Hallo, Ewald.

Ich bin hier eigentlich regelmäßig aktiv. Trotzdem - danke!

Wenn es nur an einem Arbeitsplatz bei einem bestimmten Benutzer auftritt - ist dessen DCLIPX.DLL übereinstimmend mit denen der anderen Arbeitsplätze bzw. aus der Auslieferung?

Und, wie gesagt - das kann auch ein Fehler sein. Welche eXpress++-Version verwendest Du?

[Ewald]

Hi Tom,
die dclipx.dll liegt auf dem Server und wird von allen Arbeitsstationen genutzt. Auf den Stationen habe ich nur ein gemaptes LW mit Verknüpfungen auf die EXE.
Die Version ist 1.9 / 255.
An einen Fehler hatte ich überhaupt noch nicht gedacht, da das ganze ja wie gesagt nur nach Lust und Laune auftritt. Ist ein solcher Fehler denn wohl mal bekannt geworden ?

[Tom]

Hallo, Ewald.

Ich kann in den Dokus zu den Versionen bis einschließlich 258 keinen Eintrag zu einem passenden Bugfix finden, aber Roger schreibt auch nicht alles auf. Blöd, dass sich dieser Fehler kaum nachstellen lässt, sonst könnte man Debugcode einbauen (beispielsweise ein simples DC_Inspectobject, um die Werte aller iVars zu kontrollieren). Ich kann im fraglichen Code von Roger aber auch nichts Fehlerhaftes sehen. "isCalc" ist eine iVar von DC_XbpGet, die auf .F. defaultet und durch die DCDIALOG.CH bei Verwendung der CALCULATOR-Klausel ordnungsgemäß in Spalte 14 des Getlist-Subarrays "xGETLIST_OPTIONS2" gesetzt wird, wo sie wiederum im Zweifelsfall beim Create des DC_XbpGet abgefragt wird. Ist es möglich, dass Du an irgendeiner Stelle im GetList-Array herumpopelst?

[Ewald]

Hi Tom,
ich habe alles noch mal abgesucht. Das getlist Array packe ich nirgendwo bewußt an. Auch verwende ich nirgendwo versehentlich eine Variable iscalc.
Eine blöde Frage vielleicht, aber kann ich irgendwo iscalc ständig abfragen ? Wann und wo wird denn diese variable aktiv ? Wenn ich die Fehlermeldung richtig
lese steht doch irgendwann statt .t. oder .f. etwas anderes drin.
Ich dacht an sowas wie

05,05 dcsay {||if (!type("iscalc")="U",iscalc,"unbekannt")}

geht aber nicht. iscalc ist danach immer "U". Egal was ich in dem Programm unternehme. War wohl etwas blauäugig.

[Koverhage]

Hallo Ewald,

iscalc dürfte auch eine lokale Variable sein, von daher wirst Du immer "U" als Rückgabe bekommen.

[Ewald]

Hi Klaus,
Da war ja der Wunsch der Vater des Gedanken. Ich dachte es gibt irgendeine Möglichkeit der Abfrage - ohne das ich in die DCLIPX eine Abfrage bastele. Mir ist wie gesagt überhaupt nicht klar, wann diese Variable überhaupt ins Spiel kommt. Und das nur ab und zu.

[Martin Altmann]

Ewald,
nicht type("iscalc"), sondern valtype( ::iscalc ) - natürlich an der richtigen Stelle, also innerhalb der Klasse!

Viele Grüße,
Martin

[Koverhage]

siehe Ausführung von Tom um 16:03

[Magic]

Hartnäckiger Fehler – durchaus eine nicht alltägliche Ursache …

Wenn ich Deinen Post so lese und mich etwas zurückerinnere stolpere ich über einen sehr merkwürdigen Fehler, der bei uns vor schon längerer Zeit in Zusammenhang mit zwei Xbase Programmen auftrat. Wir konnten uns damals keinen Reim drauf machen und haben schließlich nach einer langen Suche – und eher durch Zufall – die Ursache gefunden.
Und irgendwie werde ich das Gefühl nicht los, dass ich durchaus parallelen erkennen kann.

Die Ausgangslage war eine Ähnliche. Zwei – völlig unabhängige – Xbase Programme liefen auf einem PC. Ganz selten kam es vor, dass das eine Programm ein merkwürdiges Verhalten an den Tag legte. Eine lange Suche begann. Datenbanken würden geprüft, Quellcode gesichtet, debuggt. Alles ohne Erfolg. Dann habe ich angefangen etliches, z.B. Variableninhalte zu protokollieren. Alles ohne den erhofften Erfolg. Irgendwann (es müssen Monate vergangen sein) kamen wie ein Stück näher und konnten den Fehler ab und an (leider nicht regelmäßig) nachstellen. Wenn er auftrat, dann wurde zuvor in beiden Programmen ein bestimmter Prozess in einer bestimmten Reihenfolge durchgeführt.
Wir sprechen hier immer noch von zwei unterschiedlichen Programmen!
Also habe ich angefangen auch das zweite Programm zu protokollieren. Nach einer weiteren langen Zeit – ich habe die Suche fast aufgegeben, denn gefunden habe ich bis dato eigentlich nicht – habe ich mich nochmals hingesetzt und die Protokolle beider Programme parallel verglichen. Dabei fiel mir eines auf:
Zur der fraglichen Zeit, zu der der Fehler auftrat wurde erst von dem einem, dann von dem anderen Programm eine lokale(!) Variable gefüllt, die in beiden Programmen aber unterschiedlichen Funktionen (können auch Methoden gewesen sein) denselben Namen hatte. Eigentlich nichts Ungewöhnliches. In diesem Fall aber schon! Denn aus uns völlig unerklärlichen Gründen, hatte die Variable im dem Programm das sich merkwürdig verhalten hatte, den Wert jener Variable aus einem völlig anderem Programm erhalten. Mit Hilfe der Protokolldateien konnten wir damals das Fehlverhalten sogar im Debugger nachstellen.
Aus welchen Gründen ein Programm in den Speicher eines anderen geschrieben hat, und dann noch exakt an die Stelle einer gleich benannten Variable, blieb unerklärt.
Ich meine wir haben dann eines dieser Programm geändert und später sogar den RAM Speicher des Rechners getauscht. Dann war auch Ruhe.

Ob dies evtl. auch bei Dir passiert, ist fraglich. Dass ein Programm in den Speicherbereich eines anderen schreibt, ist schon sehr skurril, aber eben nicht unmöglich. Die Ursache mir unbekannt. Will damit nur sagen, dass es sich evtl. lohnt auch Dein anderes Programm genauer anzugucken. Es gibt eben Sachen, die sollte es eigentlich nicht geben …

[brandelh]

Hi,

dass der NAMEN einer LOCAL Variablen zur Laufzeit eine Rolle spielt ist unmöglich, denn dieser wird vom Compiler in einen Pointer umgesetzt.
Eingentlich hat auch eine EXE nichts im Speicherbereich einer anderen zu suchen, aber der tatsächlichen Schutz wurde erst spät eingeführt und ist standardmäßig auf Systemprozesse beschränkt.
Ich meine dass die 1.82 bzw. das Installationsprogramm damit Probleme hatte als der Schutz eingeschaltet wurde.

=> http://de.wikipedia.org/wiki/Speicherschutz

Viel wahrscheinlicher sind aber Abhängigkeiten in Dateien (DBF, NTX, INI etc.) ... oder Hardwarefehler.

[Magic]

dass der NAMEN einer LOCAL Variablen zur Laufzeit eine Rolle spielt ist unmöglich, denn dieser wird vom Compiler in einen Pointer umgesetzt.

Aus welchen Gründen ein Programm in den Speicher eines anderen geschrieben hat, und dann noch exakt an die Stelle einer gleich benannten Variable, blieb unerklärt.

Dass ein Programm in den Speicherbereich eines anderen schreibt, ist schon sehr skurril, ...

Viel wahrscheinlicher sind aber Abhängigkeiten in Dateien (DBF, NTX, INI etc.) ... oder Hardwarefehler.

... und später sogar den RAM Speicher des Rechners getauscht

[Ewald]

Mojn zusammen,
ich werde heute mal die Arbeitsstation austauschen und in den Programmen alle Variablen umbenennen. Ein Hardwarefehler, der nur an einer Stelle auftritt und immer nur eine einzige Variable beeinflusst wäre schon hart, aber eben nicht unmöglich.

Das Variablen aus 2 verschiedenen EXE sich nicht in die Quere kommen können war meine feste Voraussetzung. Eigentlich ist das der Grund, warum ich überhaupt in verschiedene EXE trenne. Nur - grau ist alle Theorie. Das Problem ist nun mal da. Natürlich greifen beide Programme im Netz auf die gleichen Datenbanken, aber wie das diesen Fehler verursachen sollte ist mir völlig schleierhaft. Was Magic da beschreibt kommt der Sache tatsächlich sehr sehr nahe. Möglicherweise spielt es auch überhaupt keine Rolle, das das zweite Programm auch eine XBase++ Anwendung ist.

Es würde mich aber stören, wenn sich dieses Problem durch Tauschen von Hardware und anderem Rumgestocher erledigt und der Auslöser im Dunkeln bleibt.
Darum noch mal meine Frage, wie und ob ich diese Variable überwachen kann. Wenn es knallt geht es ja immer nur um ::isCalc

@Tom, wie mache ich das denn mit dem von dir vorgeschlagenen "DC_Inspectobject" wohl am Besten. Habe ich mich noch nie mit beschäftigt. Kann ich das mit einem Pushbutton auslösen oder permanent anzeigen ?

[Tom]

Ich halte es für absolut ausgeschlossen, dass unterschiedliche Xbase-Programme gegenseitig lokale Variablen überschreiben. Vielmehr halte ich es für äußerst wahrscheinlich, dass ein Programmierfehler vorlag - Typos beim Laden von INI/XPF/XML/DBF-Daten oder ähnliches. Die Programme haben vermutlich by code Daten ausgetauscht, und es wurde nur an der falschen Stelle nach dem Fehler gesucht. Darauf würde ich eine Menge verwetten.

[Tom]

Hallo, Ewald.

Tom, wie mache ich das denn mit dem von dir vorgeschlagenen "DC_Inspectobject" wohl am Besten. Habe ich mich noch nie mit beschäftigt. Kann ich das mit einem Pushbutton auslösen oder permanent anzeigen ?

Du kannst DC_InspectObject(oObject) jederzeit auslösen (natürlich auch über einen Pushbutton - oder im GOTFOCUS-Slot), wenn Du weißt, was "oObject" ist. Das ist in Deinem Szenario ein wenig problematisch, da Du mit einem DC-Editbrowse arbeitest, also keine direkte Kontrolle über die entstehenden DC_XbpGet-Objekte hast. Ich schaue mir das nachher mal an (ich arbeite nicht so) und versuche, ein kleines Beispiel zu bauen.

[brandelh]

Was verstehst du unter Überwachen ?

In einem "normalen" Programm könntest du in der Eventloop einen Zähler einbauen, dass alle Sekunde den Wert überprüft bzw. wenn ein bestimmtes Objekt einen Event ausgelöst hat.
Das macht dem Rechner aber auch jede Menge Arbeit, vorallem wenn du das auf die Platte schreiben willst.
wenn nur der Wert als solcher geprüft werden soll, kannst du auch einen Thread aufmachen, die Var als Parameter übergeben und der prüft dann den Wert ...

kannst du genauer definieren, was als Fehler gilt und wie du den erkennst ?

Beispiel aus dem Handbuch, so wie du hier die Zeit ausgibst, könntest du eine Funktion aufrufen die die Werte vergleicht ...

Code: Alles auswählen

SetTimerEvent(100, {|| DispOutAt(0, 0, Time()) } )

[Magic]

Ich halte es für absolut ausgeschlossen

Hallo Tom,

ich selbst neige dazu (und die Erfahrung bestätigt es), etwas das mir „Benutzer“ beschreiben selbst sehen zu müssen, um dann zu sagen glaube ich oder eben nicht. Entwickler und Benutzer haben da manchmal eine andere Auffassung von Fehlern, Daten, …

In diesem Fall muss ich Dir widersprechen
Wir, 3 Entwickler (zwei davon Senior) haben es sehen und sogar nachstellen können.

Mann kann es also glauben, … muss man aber nicht

[Tom]

Hallo, Magic.

Wir, 3 Entwickler (zwei davon Senior) haben es sehen und sogar nachstellen können.

Dann gibt es sicher auch ein (kleines) Testprogramm, mit dem sich das anschauen und nachstellen lässt. Her damit! Und ab damit nach Alaska!

Die Wette gilt nach wie vor.

[Ewald]

Hallo Hubert,
wie oben in der Fehlermeldung geschrieben knallt die Anwendung ja alle Jubeljahre mit abgebildeten Fehlermeldung ab. Der Varaiblen ::isCalc in DC_XbpGet wurde ein falscher Wert zugewiesen. Da ich nicht die geringste Ahnung habe wann diese Variable ins Spiel kommt und was sie wann enthält wenn sie existiert bin ich halt auf die Idee gekommen, sie zu kontrollieren. Also was in meine Anwendung zu basteln, das mir ständig anzeigt ob diese Variable existiert und wenn, was sie enthält. Dann könnte ich testen, was wann passiert.

[Koverhage]

So etwas hartnäckiges hatte ich vor kurzem auch.
Eine Privat oder Local Variable Epreis und dann als letztes eine DBF geöffnet, welche auch ein Feld Epreis hatte.
Dann den Epreis errechnet, aber da stand nichts drin. Den Fehler zu finden hat etwas gedauert

[Manfred]

Deswegen soll man ja auch immer den Alias davor schreiben, dann passiert sowas nicht.

[Tom]

Hallo, Ewald.

Also was in meine Anwendung zu basteln, das mir ständig anzeigt ob diese Variable existiert und wenn, was sie enthält.

"isCalc" ist eine Instanzvariable der Klasse DC_XbpGet. Es gibt sie nicht einmal in Deiner Applikation, sondern (ggf. vorübergehend) für jedes DC_XbpGet-Objekt, das erzeugt und verwendet wird. Das geschieht - wie bei Dir - beispielsweise vorübergehend in einem editierbaren Browse, aber auch, wenn Du mit @ x,y DCSAY ... GET arbeitest. Wenn Du das um "GETOBJECT oGet" ergänzt, kannst Du z.B. mit einem Pushbutton @ x,y DCPUSHBUTTON CAPTION 'Test' SIZE 5,1 ACTION {||DC_InspectObject(oGet)}" anschauen, wie das Objekt aufgebaut ist und was die Instanzvariablen enthalten. Die Variable "isCalc" (obere Tabelle) wird dann auf "No" (.F.) stehen.

In Deinem Szenario ist das etwas komplizierter, da Du ein simples Editbrowse verwendest. Das könntest Du so abändern:

Code: Alles auswählen

DCBROWSECOL FIELD db->name PARENT oBrowse WIDTH 10 ... EDITOR "myget"
...
@ nil,nil DCGET db->name GETID "myget" OBJECT oMyGet

In diesem Moment siehst Du das Get-Objekt ("oMyGet") und kannst es inspizieren, etwa über die POPUP-Klausel:

Code: Alles auswählen

@ nil,nil DCGET db->name GETID "myget" OBJECT oMyGet POPUP {||DC_InspectObject(oMyGet),db->name}

Der Rückgabewert "db->name" im Popup ist nötig, weil DC_InspectObject keinen für das Get sinnvollen Wert zurückgibt (sondern einen langen String mit Informationen über das Objekt).

In diesem Szenario könntest Du das Get-Objekt auch überwachen, aber ich wage zu bezweifeln, dass das von Hubert angeregte "SetTimerEvent" dafür sinnvoll ist, da der Timer viel zu selten "zuschlägt". Bei einem Überwachungsintervall von einer hundertstel Sekunde können tausende Operationen übersehen werden.

Problematisch ist ja auch, dass sich das Verhalten nicht nachstellen lässt. Damit scheitern auch Testprogramme.

Übrigens gab es dieses Thema bereits einmal in Rogers Forum:

http://bb.donnay-software.com/donnay/vi ... calc#p3948

Rogers Anmerkung hierzu lautete, dass das Problem daran liegen könne, dass sich der Datentyp des Gets geändert hatte. Erst war der zu editierende Wert numerisch, dann plötzlich eine Zeichenkette oder so.

[Ewald]

Und was meint der geneigte User zu diesem Thema ...
Richtig...
"Was haben Sie denn da für einen Mist gebaut ? Stellen Sie das gefälligst ab, so schwer kann das doch nicht sein "
An der letzten XXX Zeitung hang eine DVD mit kostenlosen Tools, die so was sicherlich auch abstellen können
Ich frag mal meinen Sohn/Schwager/Nachbarn, die können sowas