plötzliches Programmende

[Pichel]

Hi.

Habe ein recht speicherintensives Programm welches bis gestern auch stabil lief geschrieben.

Nachdem ich gestern wieder mal kleine Änderungen vorgenommen habe (nichts laufzeitkritisches) kommt es gelegentlich vor, dass sich das Programm ganz kommentarlos und plötzlich beendet (es ist einfach plötzlich weg) und die Close-Events wurden dann auch nicht abgearbeitet.
Es kommt dabei auch keinerlei Meldung... nix.. einfach weg.

Hat jemand ne Idee wo ich da ansetzen kann?

Grüße aus Kassel.

[mkinzler]

-Die Änderungen nochmal genau ansehen
-Im Debugger Starten
-Logging implementieren

[Corpsman]

Wenn du sagst das du was geändert hast und nun ist der Fehler da dann ist doch Klar wo du ansetzen must.

Am einfachsten machst du die Änderung Rückgängig und schaust ob der Fehler dann tatsächlich weg ist.

Für jeden weiteren Tipp müsstest du wahrscheinlich deutlich mehr Informationen ( sprich Source Code ) zur Verfügung stellen.

[hoika]

Hallo,

MadExcept benutzen


Heiko

[Pichel]

Nun.. also die Änderungen sind im optischen Bereich.. Aligns... SetBoundsRect etc... nix wildes...

und wenn ich wüsste welchen Codeabschnitt es betrifft hätte ich ihn gepostet, aber 17000 Zeile will ich Euch nicht antun.

Das komische ist nur, das keinerlei Meldung kommt.

[sh17]

Irgend welche externe Komponenten im Einsatz?

Bei mir haben z.B. die VirtualShellTools mal solche Späne gemacht. Und das nicht auf jedem Rechner. Hab schön gesucht.

[oldmax]

hi
Nur so ne Idee, könnt's sein, das es irgendwo ein ".Free" auf die Aktive Form zur Ausführung kommt ? Immerhin ist dann deine Anwendung ohne OnClose Ereignis verschwunden....
Ein Speicherproblem möcht ich ausschließen, da sorgt schon das System in der Regel für. Und wär's denn dann doch tatsächlich eines, ginge dein Rechner auch gleich mit ins Nirwana.
Gruß oldmax

[yörsch]

Erstmal Moin Moin! :hi:
Ich höre :

Zitat:

Zitat von Pichel

Änderungen sind im optischen Bereich...

wenn du durch dein neuen Code nur kurzzeitig einwenig speicher mehr gebraucht wird,
dann konntest du Prozeß/Thread grenzen stosen? Dann müste es aber Irgendeine fehlermeldung geben? :gruebel:
Wer das mit Bildern / Optik / Oberfläche arbeitet sollte immer genügent Speicher haben..
Kannst du mal die Speicher auslastung prüfen?
und ein Bild deiner Oberflächliochen Veränderung, also vorher und nachher posten?

[mkinzler]

Hast du schin mal nachgesehen, ob Windows was protokolliert hat?

[Pichel]

Zitat:

Zitat von sh17

Irgend welche externe Komponenten im Einsatz?
Bei mir haben z.B. die VirtualShellTools mal solche Späne gemacht. Und das nicht auf jedem Rechner. Hab schön gesucht.

Klar sind da einige im Einsatz
Die größte ist VirtualTreeView hat aber bisher keinerlei Probs gemacht.

Im der Windows Ereignisanzeige ist auch nichts passendes zu sehen.

Werde das Prog.. nachher mal länger unter Delphi laufen lassen, vielleicht kommt dann ja ne Meldung.

[Corpsman]

Bei meinem Balanced ist das Übrigens auch so.

Und wenn ich das Normal Starte ist dann tatsächlich einfach weg ( weil OpenGL leider auch Bugs hat ).

Wenn ich es aber via Compiler starte dann "Merkt" der den Fehler wirft plötzlich ne AV und springt dann an die entsprechenden Codezeile in der der OpenGL befehl aufgerufen wird.

Vielleicht hast du ja Glück und dein Programm zeigt dir so den fehler.

[Oxmyx]

Zitat:

Zitat von Corpsman

Wenn du sagst das du was geändert hast und nun ist der Fehler da dann ist doch Klar wo du ansetzen must.

Am einfachsten machst du die Änderung Rückgängig und schaust ob der Fehler dann tatsächlich weg ist.

Für jeden weiteren Tipp müsstest du wahrscheinlich deutlich mehr Informationen ( sprich Source Code ) zur Verfügung stellen.

Leider ist es in solchen Fällen oft nicht so einfach. Die schlimmsten Fehler sind nämlich die, die irgendwo tief drin sitzen und gar nichts böses machen. Und irgendwann macht man dann etwas, was mit dem Fehler in keinem Zusammenhang steht - und plötzlich stürzt halt mal alles kommentarlos ab. Das können wilde Zeiger sein, die nie eine Schutzverletzung auslösen, und auf einmal durch ne völlig andere Sache das gesamte Programm crashen. In solchen Fällen hilft nur viel Geduld bei der Fehlersuche. ;)

[thkerkmann]

Hi,

also ich habe folgende Erfahrung gemacht - zumindest mit D5:

Ein kommentarloser Absturz tritt ein wenn eine Gleitkomma Division durch null oder nahe null geschieht. Anscheinend kann Delphi dort keine Exception erzeugen, oder bekommt den Trap vom Gleitkommaprozessor nicht mit. Wenn ich sowas habe schaue ich mir alle Rechenoperationen genau an. Meist liegt es nicht an grundlegenden Programmfunktionen, sondern - ähnlich wie bei dir - an visuellen Gimmicks wie Progressbar oder so, wo man dann schonmal schlampig mit den Operationen zur Normierung auf 100% umgeht.

Dies ist nur ein Tip und keine Lösung, aber schau mal in diese Richtung, ich wette du findest was :-)

Gruss

[turboPASCAL]

Hmmm, ja sowas habe ich auch schon erleben müssen.

Meistens ist irgend ein Überlauf oder Zugrifsverletzung daran Schuld. Wenn Du mit der VCL
arbeitest würde ich dir Vorschlagen einen ApplicationEvent auf die Form zu legen und mit
dessen Hilfe die OnException auszuwerten.

Weiter ist es eine Möglichkeit mit Hilfe von FastMM oder MemProof nach Fehlern zu suchen.

// Edit:

MemProf zu MemProof. :wall:

[Sidorion]

Kann das sein, dass Du Threads benutzt?
Bei denen ist nämlich das Problem, wenns ne exception gibt, das Verhalten innerhalb und ausserhalb des Debuggers ein völlig anderes ist: Im Debugger handelt Delphi das Ganze und die Applikation läuft weiter (man kriegt also nichtmal was davon mit). Ausserhalb haldelt das das BS und beendet die Applikation kommentarlos.
Falls Du Treads benutzt, schau also mal nach, ob es zu Verletzungen innerhalb des Threads kommt.

[sh17]

Zitat:

Zitat von Sidorion

Kann das sein, dass Du Threads benutzt?

Was war auch bei den VirtualShellTools der Fall. Nur den Fehler da selbst zu suchen, kann man vergessen.

Tritt den der Fehler wirklich so "zufällig" auf, tritt er auf jedem Rechner auf?

[MStoll]

Ich hatte das Problem auch mal mit 2 verschiedenen Ursachen (unabhängig voneinander):
1. ein Stack-Overflow (was auf dem einen Rechner eine Exception verursachte, auf dem anderen das Programm verschwinden ließ wie bei dir jetzt)
2. der FastShareMem-Memory-Manager.

Der Memory-Manager war das schlimmere Problem:
Ganz tückisch war, dass sich mein Programm erst nach langer Zeit (1 - 5 Stunden) beendet hat, so war das Debuggen recht schwierig.

Ich habe auch ca. 25.000 Zeilen Code, benutze Threads, einige DLLs, tausche mit denen Objekte, strings und dyn. Arrays aus.
Erst seit ich den FastShareMem durch den NexusDB-MM ersetzt habe, funktioniert alles einwandfrei.

Wenn du also einen anderen Speichermanager benutzt, tausch ihn mal aus.

Gruß
Michael

[Pichel]

Also hab jetzt unter Delphi 7 Pro das Programm laufen lassen und bekomme nen EStackOverflow Meldung Stack Überlauf.

Gehe ich dann schrittweise weiter läuft er in das SetText Event von TJvSpinEdit

und danach kommt CPU fenster mit push ebx womit ich nun nixh mehr anfangen kann.

[sh17]

Wenns denn das ist, würde ich es testweise gegen einen normales SpinEdit austauschen, oder im SVN von der JVCL die aktuellen Quellen mit Deinen vergleichen. Man muss ja nicht sinnlos rumsuchen.

[Christian Seehase]

Moin Pichel,

die Verwendung von MemProof (@Matti: Mit zwei o ;-)) kann eventuell auch weiterhelfen.

Hast Du, zum Testen, auch mal solche Optionen wie RangeChecking aktiviert?

[turboPASCAL]

Zitat:

Zitat von Chris

(@Matti: Mit zwei o ;-))

:wall: Jupp, hab es mit Tipp-Ex koorrigiert.

[Pichel]

So... erstmal vielen Dank für die Hilfe.

Der Compiler hat den Crash ja angezeigt und daher kam ich auf das TJvSpinEdit.

Nun hab ich das Problem behoben indem ich über eine globale Bool-Variable das mehrfache/verschachtelte Aufrufen des OnChange verhindert und es ist wieder Ruhe.
Irgendwie ist es zwar kein "richtiger" Loop aber irgendwo verzweige ich wieder in das OnChange bzw. ändere den Wert des TJvSpinEdit wären es bereits geändert wird. Muß das nur noch finden ;-)

Also erledigt und Danke!