Programm stürzt bei "end;" ab

[Synollus]

Ich weiß ja nicht, ob ihr mich jetzt für verrückt haltet, aber mein Programm stürzt im Einzeldurchgang mit F7 ab, wenn er ALLES abgearbeitet hat und er schon bei der Zeile end; (Ende der Procedure) ist, sprich bevor er die Form wieder anzeigen soll. Auch ohne Einzeldurchlauf geht es nicht. Ich kriege immer eine AccessViolation:

---------------------------
Benachrichtigung über Debugger-Exception
---------------------------
Im Projekt Purzelbaum.exe ist eine Exception der Klasse EAccessViolation aufgetreten. Meldung: 'Zugriffsverletzung bei Adresse 004032FE in Modul 'Purzelbaum.exe'. Lesen von Adresse FFFFFFD0'. Prozess wurde angehalten. Mit Einzelne Anweisung oder Start fortsetzen.
---------------------------
OK Hilfe
---------------------------

Wie kriege ich von Delphi einen detallierteren Fehler? ^^ Ich kann mir den Fehler nicht erklären. Ich gebe vorher Labels auf der Form frei und erstelle danach wieder welche. [Es dürften imho keine doppelten Namen geben, sonst würde er keine AV ausspucken, sondern ein "LabelX existiert schon." und das schon viel früher.] Und irgendwie scheint er damit Probleme zu haben. (Vorher ruft er eine Rekursion auf, malt ein bisschen in die Paintbox und erstellt ein paar Labels, genaugenommen geht es um das Anzeigen eines binären Suchbaumes (eigentlich würde ich alles mit Canvas machen, aber ich kann auf eine Art OnClick-Procedure der Knoten/Werte nicht verzichten.).)

Ich bin echt ratlos, was soll ich jetzt tun? Ich denke nicht, dass es am "end;" selbst liegt. Gibt es eine Möglichkeit eine bessere Fehlerbeschreibung zu kriegen?

[3_of_8]

Du könntest mal im CPU-Fenster durchsteppen, aber ich denke nicht, dass das etwas bringt. Du könntest auch mal FastMem (heißt doch FastMem, oder? Weiß ich jetzt gar nicht mehr so genau) installieren, das ist ein Memory Manager, der sich genau merkt, wann was alloziert wurde und meckert, wenn man es nicht mehr freigibt, das wäre eine Möglichkeit. Du könntest auch mal deinen Code herzeigen, dann kann man sich vielleicht eher ein Bild davon machen.

EDIT: Schalte auch mal die Range Checks ein. Der Fehler sieht mir irgendwie fast danach aus, als würdest du irgendwo in einem Array außerhalb der Grenzen zugreifen oder sowas... schwer zu sagen, natürlich.

[Cyf]

Das klingt als wäre der Aufrufstack zerschossen.

[Mithrandir]

MadExcept ist ne feine Sache. ;)

Aber das FFFFFFD0 sieht irgendwie mysteriös aus. Biste sicher, dass du alles wieder sauber frei gibts?

[jaenicke]

Setze in der Projektdatei nach dem begin einmal ReportMemoryLeaksOnShutdown auf True. dann siehst du schon einmal, wenn der Standardspeichermanager Speicherlecks erkennt.

Dann gibts noch FastMM, das dies detaillierter auflistet, und einige andere ähnliche Tools.

[Synollus]

So,

danke euch allen erstmal. Ich schau mir gleich mal eure Vorschläge an. Ich habe mal schnell den unwichtigen Code aus meinem Programm genommen. Das Einzige was ich bewusst nicht freigebe, weil ich noch nicht soweit bin, sind die Knoten des Baumes vor dem Schließen des Programmes.

Ich habe eine globale Integer-Variable, die die erstellen Labels/Knoten mitzählt (fortlaufen numeriert), damit ich vor dem Neuzeichnen die alten Labels löschen und neue (von 1 wieder beginnend) erstellen kann. (Die Eleganz und Effizienz sei mal dahingestellt :mrgreen:)

[jaenicke]

Das einzige, was Delphi selbst findet und anzeigt sind Speicherlecks, da die Knoten nicht freigegeben werden. Abstürzen tut dein Programm bei mir aber gar nicht, es funktioniert normal.

Da du wohl noch Delphi 7 hast, musst du dir für die Anzeige von Speicherlecks andere Tools suchen, Delphi selbst kann das erst ab 2005. Ich habs eben im kostenlosen Turbo Delphi ausprobiert.

[Synollus]

Zitat:

Zitat von jaenicke

Das einzige, was Delphi selbst findet und anzeigt sind Speicherlecks, da die Knoten nicht freigegeben werden. Abstürzen tut dein Programm bei mir aber gar nicht, es funktioniert normal.

Da du wohl noch Delphi 7 hast, musst du dir für die Anzeige von Speicherlecks andere Tools suchen, Delphi selbst kann das erst ab 2005. Ich habs eben im kostenlosen Turbo Delphi ausprobiert.

Habe ich auch schon gemerkt mit den Tools. :D

Zu dem Fehler: Ich habe wohl ganz vergessen zu erwähnen wo ihr suchen müsst. :mrgreen: Gib mal eine "1" ein, danach eine "2" und dann klick mal auf die 2 im Baum. Dadurch wird nochmal die Prozedure Refresh aufgerufen. Und danach stürzt er bei mir ab.

[Klaus01]

Guten Morgen,

nun, wenn ich das mit der exe im Zipfile ausprobiere laufe ich
in Fehler.

Probiere ich das mit der selbst kompilierten exe, kommen keine Fehler.

Hast Du Dein Programm mal komplett kompiliert (shift-F9/Build)?

Grüße
Klaus

[Synollus]

Zitat:

Zitat von Klaus01

Guten Morgen,

nun, wenn ich das mit der exe im Zipfile ausprobiere laufe ich
in Fehler.

Probiere ich das mit der selbst kompilierten exe, kommen keine Fehler.

Hast Du Dein Programm mal komplett kompiliert (shift-F9/Build)?

Grüße
Klaus

Jup. Wenn ich F9 drücke und 1,2 eingebe und auf die 2 klicke, kommt genau derselbe Fehler. :wall:

ich muss jetzt erstmal auf den Wandertag. Mathe LK12 vs. Mathe LK13 Fussballspiel. :mrgreen: Danach lade ich mir mal eines dieser Tools runter.

[Klaus01]

Zitat:

Zitat von Synollus

Jup. Wenn ich F9 drücke und 1,2 eingebe und auf die 2 klicke, kommt genau derselbe Fehler. :wall:

Ich meinte schon shift+F9 (build,erzeugen), dann werden auch die Units neu erstellt.
Vielleicht schlummert da ja das Problem.

Viel Spass beim Wandertag.

Grüße
Klaus

[himitsu]

warum der abstürzt?

also erstmal hättest du gleich von Anfang an sagen können, wie man den Fehler produziert, wenn es nicht von alleine geschieht.

und dann wäre es schön gewesen, wenn du auch sagst wo der Fehler auftritt. :warn:
(wir können ja nicht bei Jedem hier im Forum auf die Suche gehn, nur weil nichts beschrieben ist ... wir haben doch nicht unendlich Zeit)


du löschst alle Labels

Delphi-Quellcode:

procedure TfrmMain.Refresh;
  ...
  For J := 1 to NrLabels do
    TLabel(FindComponent('Knot' + IntToStr(J))).Free;

und dann ist es doch kein Wunder, wenn er abstürzt, sobald er zu dem Label zurück will, von wo aus der Aufruf gestartet wurde.

Delphi-Quellcode:

procedure TfrmMain.LabelClick(Sender: TObject);
begin
  Refresh;
end; <<<<<<< der Absturz

wenn ich dir jedesmal das Haus unter den Füßen wegzieh, sobald du ein anderes Zimmer betrittst, dann stürzt du auch ab ... da isses egal, ob ich das Haus gleich wieder neu Aufbaue ... wobei hier das Haus (also das Label) sogar noch an einer anderen Stelle (wo anders im Speicher) neu aufgebaut wird.

[Klaus01]

@himitsu
.. die Labels werden aber in der draw Routine wieder erstellt.

Grüße
Klaus

[himitsu]

ja klar, aber er ist im OnClick einer der Labels und zieht sich das Label unterm Arsch weg ...
da ist es egal ob die dann wieder neue Labels erstellt werden ... das Label, welches in der Ausführung war, ist weg
und es wurde stattdessen nur ein neues/anderes Label erstellt.

[Synollus]

Danke himitsu. Ich war zu blöd, dass zu checken. :D

Ich sitze jetzt schon daran den Fehler zu beheben, aber mir fällt keine Möglichkeit ein beim Click Code auszuführen und vorher die aktuelle Methode zu verlassen.

Momentan habe ich die Aktualisierung des Baumes in einem Extra-Button, den ich per Hand anklicken muss, aber das soll ja nicht der Sinn sein. Dann bräuchte ich auch keine Labels. Es soll schließlich anwenderfreundlich sein. :mrgreen:

Gibt es eine Möglichkeit das zu umgehen? Spontan fällt mir nur ein, das in einen deaktivierten Timer zu schreiben und ihm am Ende des Oncliks einzuschalten, der sich dann wieder selber nach Ausführung des Codes abschaltet. Ich bin mir aber nicht sicher, ob er da nicht danach doch wieder in die OnClick-Prozedur zurück will. Und außerdem ist diese Lösung nicht schön. :mrgreen:

[himitsu]

nja, zumindestens das aktualisieren, könntest du über Messages lösen.

du sendest im OnClick der Labels z.B. eine selbsterstellte Windows-Nachricht an das Propgrammfenster ... und wenn diese empfangen wird, aktualisierst du die Liste.

wenn nicht explizit innerhalb der Click-Prozedur z.B. Application.ProcessMessages ausgeführt wird, dann wird die Botschaft erst nach Ende der ClickProzedur ausgeführt.

[hoika]

Hallo,

was mir am Programm aufgefallen ist.
Das 1 , 2 hinzufügen.

Fenster kleinmachen, wieder grossmachen -> Linie ist weg.

Das Problem:
Du musst das Malen im OnPaint machen

Zum "Anstossen" des OnPaint rufst Invalidate auf.

Und wird es kompliziert,
da du ja immer alle Labels löscht und wieder anlegst.


Heiko