Interne Datenstrukturen beschädigt von XBPCOMBOBOX(95) [ERL]

[Martin Altmann]

Hmmm - ich fürchte fast, es ist ein Ressourcenproblem! Und darum merkst Du davon nichts
Zu wenig handles (GDI bzw. User) - jedes einzelne Arrayelement braucht z.B. schon einen Handle.
Könntest Du irgendwie in Erfahrung bringen (lassen), wie die Ressourcen bei den betroffenen Leuten zum Zeitpunkt des Absturzes aussehen?

Viele Grüße,
Martin

[Tom]

Interessanter Gedanke. Läuft bei diesen Kunden möglicherweise Windows 9x?

[Jan]

Wäre natürlich eine Möglichkeit. Ich kann mich erinnern, das Till oder Andreas in Berlin einen Vortrag darüber gehalten haben. Ich bekomme das nicht mehr ganz zusammen, aber ich erinnere mich daß wir überrascht waren als er erzählte, das zu irgendeiner Windows-Version hin die zur Verfügung stehenden Handles sogar weniger wurden. Oder irgendwas in der Richtung.

Hier würde sicherlich Memwatch helfen. Damit kann man die zur Verfügung stehenden und belegten Handles gut verfolgen.

Jan

[Tom]

Die 9x-Versionen von Windows sind stark ressourcenbegrenzt, was GDI-Objekte und Handles dafür anbetrifft. Ich musste seinerzeit komplexe Dialoge so aufbauen, dass ein Teil der Objekte nur "on call" erzeugt und danach wieder zerstört wurden, sonst grätschte die App ins Nirwana oder verabschiedete sich mit Fehlern, darunter möglicherweise auch IDSCs (ich weiß es nicht mehr genau, ist schon echt lange her). Allerdings haben wir 9x schon vor Jahren als unterstützte Betriebssystemversionen abgekündigt, und unsere App lässt sich dort auch nicht mehr starten.

[Jan]

Tom,

soweit ist das schon klar. Ich meinte mich aber erinnern zu können, daß es später einmal eine Verringerung irgendwelcher Handles gegeben hat. Ob jetzt von 2000 nach XP oder XP nach Vista weiß ich wie gesagt nicht mehr. Ich kann mich aber gut erinnern, das in der betreffenden Session der 2007er DevCon ein ungläubiges Raunen durch das Auditorium ging, als das erklärt wurde.

Jan

[Rolf]

@Tom in der Regel WinXP

Haben uns die Logdateien angesehen, der Fehler mit dem XbpCrt im ersten Posting tritt 264 mal auf
der Fehler mit XbpCombobox tritt 91 mal auf
und dann gibt es noch einen ähnlichen Fehler mit XBPSPINBUTTON(128) tritt 29 mal auf.

Weiß nicht ob das mit dem XbpCrt in einen extra Thread soll?
Wir haben ca. noch 15 Crts in der Anwendung, bei einigen kommt es zu dem Fehler.
Eine Begebenheit dazu:
Chef geht hin, Kunde sagt kommen sie bitte mit rüber.
Drückt die Tastenkombination mit welcher das Crt geöffnet wird,
Anwendung stürzt bei oCrt1:Create() ab.
Startet Anwendung wieder, Fehler nicht wieder reproduzierbar.

@Martin
wie bekommt man die Handles aus dem XBase-Programm ausgelesen, mit "Process Explorer" kann ich die mir ansehen?

[Martin Altmann]

Yup,
Process-Explorer ist gut! Wenn der Chef mal wieder "rübergerufen" wird:
Im Process-Explorer nach Ressourcen schauen, Taste im Xbase++-Programm drücken und Absturz provozieren und dabei den Process-Explorer beobachten.
Wobei das wahrscheinlich zu schnell gehen wird.
Oder mit Memwatch.dll-Integration arbeiten.

Viele Grüße,
Martin

[Rolf Ramacher]

Rolf

Ob das mit xpbcrt() zusammenhängt. kannst du das gleiche mal mit GUI-Testen ?

[Tom]

Mmh. Kann es sein, dass Du nicht ganz sauber mit Klassenobjekten arbeitest? Es klingt danach, als würdest Du Objekte mehrfach oder wiederverwenden. Ein bereits "lebendes" Objekt, das hinterrücks umbestückt wird, dürfte sauer darauf reagieren. Will sagen, wenn Du z.B. oCrt1 erzeugst und sogar anzeigst (oder nicht ordnungsgemäß entsorgst), um kurz darauf einen neuen Dialog in dieselbe Variable zu stecken, wäre es möglich, dass Du Konflikte heraufbeschwörst. Dagegen hülfe, nur mit lokalen Variablen, mit unterschiedlichen Variablennamen oder mit Threads zu arbeiten. Aber auch dieses Problem müsstest Du eigentlich nachstellen können. Schon die einfache Anzeige von oCrt:ChildList() bei jeder Neuerzeugung des Klassenobjekts könnte Hinweise liefern.

[Martin Altmann]

Yup - oder dettached locals, die Referenzen auf Objekte behalten - über die "Lebenszeit" des Objektes hinaus (also nicht ordentlich geNILt oder destroyed werden)...

Viele Grüße,
Martin

[Markus Walter]

Tom,

soweit ist das schon klar. Ich meinte mich aber erinnern zu können, daß es später einmal eine Verringerung irgendwelcher Handles gegeben hat. Ob jetzt von 2000 nach XP oder XP nach Vista weiß ich wie gesagt nicht mehr. Ich kann mich aber gut erinnern, das in der betreffenden Session der 2007er DevCon ein ungläubiges Raunen durch das Auditorium ging, als das erklärt wurde.

Jan

Hi Jan,

wenn ich mich recht entsinne, sind es unter TerminalDiensten deutlich weniger (zumindest bei der damaligen OS-Version).

[brandelh]

Hi,

genau, die "exclusiven" Win2000 Nachfolger haben mit den Handles gegenüber den Win98 die Grenzen weit verschoben ...
Wenn allerdings "EIN" Server für viele Anwendungen bereitstellen muss, werden die - soweit ich mich erinnere - auf 1/4 der
"normalen" Werte reduziert - wie soll er das auch sonst schaffen

Allerdings sind das immer noch Welten im Vergleich zu Win9x oder DOS Zeiten.

[Rolf]

@Tom
die Crt Aufrufe sind alter funktionsorientierter Quellcode, oCrt1 ist zum Beispiel nirgends deklariert, also Private.
Bei XbpCombobox(95) müsste eigentlich alles soweit sauber sein.

Die Fehler unterscheidet sich ja auch im Vergleich.
Beim xbpCrt tritt der Fehler beim oCrt1:Create() auf und bei der
Combobox bei ::oCbxStoff := XbpCombobox():new(oOwn),
wobei er da ja schon bei ::oCbxStoff := XbpCombobox() auftritt, oder irre ich mich da?

Wie bekommt man die maximale Anzahl der Handle's, die aktuell möglich sind,
bzw. wie kann man diese in der Anwendung ausreizen, um den Fehler ggf. nachstellen zu können?

Danke für eure Mühe und Gedanken

[Jan]

Rolf,

binde die memwatch.dll mal mit ein, und ruf die in der Startroutine über DllLoad("memwatch.dll") auf. Dann siehst Du immer die aktuelle Anzahl der freien und besetzten Handles in den verschiendenen Bereichen. Außerdem kannst Du dann auch verfolgen, wo besetzte Handles eventuell nicht wieder freigegeben wurden nach Schließen eines XBParts, wo also z. B. ein :destroy() fehlen könnte.

Jan

[AUGE_OHR]

Beim xbpCrt tritt der Fehler beim oCrt1:Create() auf und bei der
Combobox bei ::oCbxStoff := XbpCombobox():new(oOwn), ...

sicherlich nicht beim "ersten Mal", oder ?
wenn du XbpCrt:create() machst, wird das XbpCrt irgendwann "gelöscht" ( :Destroy() ) und wieder neu XbpCrt:create() gemacht ? ( PDR 6256 und PDR 5634 )

Ich würde, wie schon gesagt, dringend auf die "aktuelle" Version upgraden damit wir auf dem selben Stand sind ... die SL1, mit "visual Style" gibt es jetzt ja schon 2 Jahre und die "Hotfixe" sind für die SL1 ...

[Rolf]

@Jan

Dann siehst Du immer die aktuelle Anzahl der freien und besetzten Handles in den verschiendenen Bereichen.

Ich habe damit schon experimentiert, aber bei mir steht bei Free System Resources, bei alle drei Einträgen nur "N/A". Liegt wahrscheinlich an Win2000, muss ich dann erst mal auf einem WinXP testen.

@Jimmy
ich will auch auf die v1.9.355 wechseln, aber das ist ein längerer Process.

[Rolf]

Hallo, ich wollte den weiteren Werdegang beschreiben

1. XbpCombobox ausgebaut durch Static ersetzt, erst wenn dieses angekllickt wird erscheint die Liste.
=> Teilerfolg da nur Symptombekämpfung. Problem mit Combobox nicht mehr aufgetreten.

2. CRT Problem trat immer noch auf.
EventSpy.lib geändert, so das Events ständig in Logdatei geschrieben werden.
Mit ins Project gelinkt und ausgeliefert.
=> Wies darauf hin das immer ein spezielles Formular vorm Absturz gedruckt wurde.

Dieses läd und entläd meine DLL für die Barcode-Erzeugung.

Nur wenn ich die DLL entlade und danach das CRT aufrufen -> Absturz.
Nochmal mit alter Exe mit Combobox versucht, dll entladen -> Absturz.
Die Ursache ist das DLLUnload() für alle genannten Probleme.

Die Dll wird so erzeugt, stimmt da etwas nicht?

Code: Alles auswählen

[PROJECT]
    COMPILE       = xpp
    COMPILE_FLAGS = -q -dll:DYNAMIC
    DEBUG_SAVE    = yes
    GUI           = yes
    OBJ_DIR       = .\OBJDLL19\
    LINKER        = alink
    LINK_FLAGS    = 
    RC_COMPILE    = arc
    RC_FLAGS      = -v
    PROJECTDLL19.XPJ

Oder muss man DLL's nicht entladen?

Sind erstmal froh die Ursache gefunden zu haben.
Liebe Grüße Rolf

[AUGE_OHR]

Dieses läd und entläd meine DLL für die Barcode-Erzeugung.

Nur wenn ich die DLL entlade und danach das CRT aufrufen -> Absturz.
Nochmal mit alter Exe mit Combobox versucht, dll entladen -> Absturz.
Die Ursache ist das DLLUnload() für alle genannten Probleme.

Die Dll wird so erzeugt, stimmt da etwas nicht?

Code: Alles auswählen

[PROJECT]
    COMPILE       = xpp
    COMPILE_FLAGS = -q -dll:DYNAMIC
    DEBUG_SAVE    = yes
    GUI           = yes
    OBJ_DIR       = .\OBJDLL19\
    LINKER        = alink
    LINK_FLAGS    = 
    RC_COMPILE    = arc
    RC_FLAGS      = -v
    PROJECTDLL19.XPJ

Oder muss man DLL's nicht entladen?

kommt darauf an ... aber warum überhaupt DYNAMIC ? ist es eine "externe" DLL ?

ich "lade" L&L wenn ein Report angefordert wird, wobei das "Handle" ein "fieldwide" STATIC über das ganze *.PRG ist.
"wenn" ich eine DLLunload() machen würde und dann wieder ein DllLoad() dann ändert sich das "Handle" ... und irgendwann knallt es ...

>ich will auch auf die v1.9.355 wechseln, aber das ist ein längerer Process.

dir ist klar das Arctica & Co die SL1 "voraus setzt" (sagt Alaska) ?

Code: Alles auswählen

oCrt1 := XbpCrt():New( AppDesktop(), SetAppWindow(), aPos, DEF_ROWS1, DEF_COLS1 )

was soll den der Owner sein ? nimm mal SetAppWindow() "raus"

Code: Alles auswählen

:oCbxStoff      := XbpCombobox():new(oOwn)

ich frage schon mal wieso dort keine Position und Grösse angegeben ist ?

Es wird zwar immer gesagt man könne aus einer Cl*pper Anwendung (VIO) zu einer Xbase++ Hybrid Application "erweitern", aber in der Praxis ist die "Verwaltung" deutlich schwerer als bei reinem GUI.

Code: Alles auswählen

// Cl*pper Code
...
? "Hallo"
...
// Hybrid "Erweiterrung"
oldWin := SetAppWindow()
MSGBOX("Hallo")
SetAppWindow(oldWin)
SetAppFocus(oldWin)

und so etwas dann als "Spagetti" Code ...

Haben uns die Logdateien angesehen, der Fehler mit dem XbpCrt im ersten Posting tritt 264 mal auf der Fehler mit XbpCombobox tritt 91 mal auf und dann gibt es noch einen ähnlichen Fehler mit XBPSPINBUTTON(128) tritt 29 mal auf.

em , äh ...
ich will ja nicht behaupten das meine Programme "fehlerfrei" an den Kunden gehen, aber so viele auf einmal ...

>Liegt wahrscheinlich an Win2000, muss ich dann erst mal auf einem WinXP testen.

em ...äh ... W2000 beim Kunden ... naja, aber als Entwickler
du hast doch damit noch nicht mal "visual Style" und "aktuelle" ist ja Windows 7 mit "Aero"

ich hatte es "ein mal", bei Windows 7 beta, das ein Kunde VOR mir meine Application "getestet" hat und mich dann fragte "wieso" es nicht funktioniert.
ich konnte ihm keine Antwort geben ... welch eine Blamage ... :-&

[brandelh]

Hi,

zuerst eine Frage, welche DLL nutzt du denn für die Barcode Erzeugung ?

und nun ein Tip, verzichte darauf die DLL zu entladen !

Bei der QuickPDF.DLL z.B. geht Speicherplatz verloren wenn man das tut und sie dennoch braucht (wird erst bei Programmende freigegeben).
Es ist absolut unnötig eine DLL zu entladen, das macht Windows nach dem Programmende der letzten EXE die sie benutzt

[Rolf]

@Hubert
ich benutze die PDF417.dll für den gleichnamigen Barcode, die wir selbst mal programmiert haben.
Das Unload, war für das aufräumen gedacht, doch wenn es solche Nebeneffekte erzeugt und es unnötig ist,
kommt dies wieder raus.

@Jimmy
>>ich will auch auf die v1.9.355 wechseln, aber das ist ein längerer Process.
>dir ist klar das Arctica & Co die SL1 "voraus setzt" (sagt Alaska) ?
Ja, man kann aber nicht in allen Punkten jetzt und sofort auf dem neuesten Stand sein,
dies ist schon vom finanziellen Gesichtpunkt nicht möglich.
Und wir sind mit den Möglichkeiten die uns Alaska schon jetzt mit der v1.9.331 bietet zufrieden.
Wenn Arctica dann da ist, werden wir weiter entscheiden.

>>oCrt1 := XbpCrt():New( AppDesktop(), SetAppWindow(), aPos, DEF_ROWS1, DEF_COLS1 )
>was soll den der Owner sein ? nimm mal SetAppWindow() "raus"
>>::oCbxStoff := XbpCombobox():new(oOwn)
>ich frage schon mal wieso dort keine Position und Grösse angegeben ist ?
Jimmy, das ist bzw. war doch nicht die Ursache, sondern es sind nur mögliche Schönheitsfehler.

>Es wird zwar immer gesagt man könne aus einer Cl*pper Anwendung (VIO) zu einer Xbase++ Hybrid Application "erweitern",
>aber in der Praxis ist die "Verwaltung" deutlich schwerer als bei reinem GUI.
Ja, die Anwendung ist zu 90% schon rein GUI, es gibt nur noch ein paar CRT's, diese sind aber in Bearbeitung.

>ich will ja nicht behaupten das meine Programme "fehlerfrei" an den Kunden gehen, aber so viele auf einmal ...
Die Fehler entstanden über einen Längeren Zeitraum und über alle PC's gerechnet.
Die Zahlen sollten nur auf das Verhältnis der Fehler zueinander hinweisen.
Außerdem konnte der Fehler von uns nicht nachvollzogen werden.
Wenn nach jedem Ausdruck eines speziellen Formulars ein Absturz geschieht, ist die Summe aber erklärbar.

>em ...äh ... W2000 beim Kunden ... naja, aber als Entwickler
>du hast doch damit noch nicht mal "visual Style" und "aktuelle" ist ja Windows 7 mit "Aero"
Ich als Entwickler habe einen PC und ein BS, welches in der Praxis das untere Segment darstellen.
Beründung hierfür: ich programmiere nichts rein was zu viel Performance benötigt und keine Funktion
die von einem "älteren" Betriebsystemen nicht unterstützt wird.
Mein Chef hat ein aktuelles Betriebssystem und einen hochwertigen PC, er testet alle Programme vor der Auslieferung.

Vielen Dank an Alle für eure Hilfe
Liebe Grüße
Rolf