Program crasht beim Schließen, aber...

[freejay]

... nur manchmal: Mal crasht* es, wenn es von der IDE gestartete wird - selbst wenn man "Ohne Debugger ausführen" auswählt, aber vom Explorer aus gestartet nicht... Mal umgekehrt...

Ich programmiere ja nun schon seit 20 Jahren in Delphi und konnte irgendwann jedes Problem lösen, aber hier stecke ich nun völlig fest und hab keine Ahnung mehr, wo oder wie ich suchen soll. Ich habe mittels Debugging schon ein paar mal die Stelle gefunden, an der es dann final gekracht hat: Beide Male war es ein .Destroy (auf unterster Ebene), dass ein Objekt, das bereits nil war, löschen wollte. Nur war das ein paar Tage später (in denen ich vermutlich auch Änderungen am Code vorgenommen hatte) eine andere Stelle und ein anderes Objekt!

Zum Teil kommt die Fehlermeldung auch bei einem Kollegen, bei mir und anderen aber nicht. Die Probleme haben vor ca. einem halben Jahr angefangen - den Auslöser also bei irgendeinem Update (der IDE oder von Komponenten) dürfte so gut wie unmöglich werden. Hier scheint doch irgendwas mit der Speicherverwaltung durcheinander zu gehen - oder so. Das ist mir dann echt zu hoch...

Habt Ihr noch irgendwelche Ideen, wie ich mich dem Problem nähern kann? Mir fällt nix mehr dazu ein (und es ist eines meiner wichtigsten Projekte...).



*Mit "crash" meine ich eine "Access violation".

[Sinspin]

Hallo, Ursachen, außer Programmierfehler, gibt es viele. Windows Patches, Win Defender, Virenscanner. Es kann alles sein und habe auch schon alles gehabt.
Zum Thema Programmierfehler, lass mal einen Scanner für Speicherlöcher mitlaufen. Das hat mir schon manchmal die Augen göffnet.

[jziersch]

Tip: Besorg Dir FastMem, aktiviere den FullDebugMode and lasse auf doppelt freigegebene Objekte prüfen.

[freejay]

Zitat:

Zitat von jziersch (Beitrag 1458174)

Tip: Besorg Dir FastMem, aktiviere den FullDebugMode and lasse auf doppelt freigegebene Objekte prüfen.

Meinst Du damit FastMM oder ist FastMem etwas anderes?

[MyRealName]

Er meint ganz sicher FastMM.
Auch MadExcept ist eine gute Variante, da es ja auch den StackTrace mit anzeigt. Einfach mit Reinkompilieren und fertig

[p80286]

Zitat:

Zitat von freejay (Beitrag 1458168)

Nur war das ein paar Tage später (in denen ich vermutlich auch Änderungen am Code vorgenommen hatte) eine andere Stelle und ein anderes Objekt!

Zum Teil kommt die Fehlermeldung auch bei einem Kollegen, bei mir und anderen aber nicht. Die Probleme haben vor ca. einem halben Jahr angefangen - den Auslöser also bei irgendeinem Update (der IDE oder von Komponenten) dürfte so gut wie unmöglich werden.

Das klingt doch sehr nach einer nicht initialisierten Variablen, oder einem "wildgewordenen" Pointer. die "Schuld" würde ich da nicht bei einem Update, sondern eher bei einer cleveren Lösung suchen.

Gruß
K-H

[scrat1979]

Ich hatte mal ein ähnliches Problem und bekam auf der Suche nach dem Fehler graue Haare. Ursache war letztendlich ein fehlender „override“ in der Destructor-Deklaration des selbst erstellten Objektes. Prüfe auch mal, ob überall der übergeordnete Desktruktor mittels inherited aufgerufen wird. Auch als Profi kann einem das ja mal durch die Lappen gehen... viel Erfolg!

[himitsu]

Im Delphi ist schon länger FastMM drin, aber nur in einer kleinen Version.

Außer dem einfachen MemoryLeak-Test, den man per Variable aktivieren kann, fehlt der Rest.

Beim großen FastMM kann man eben auch beim Freigeben von OLbjekten/Pointern ein Überschreiben aktivieren, was spätere Zugriffe erkennen lässt.
Normal wird Speicher ja nicht sofort freigeben und man kann nach dem Free/Destroy noch auf Einiges zugreifen, mit dem ungültigen Zeiger.

[freimatz]

Ginge das auch mit madExcept? Habe da keine Option genau dazu gefunden.

[freejay]

Zitat:

Zitat von jziersch (Beitrag 1458174)

Tip: Besorg Dir FastMem, aktiviere den FullDebugMode and lasse auf doppelt freigegebene Objekte prüfen.

Danke für den Tipp. Das werde ich mir die Tage mal ansehen.