Stack überlauf

[EWeiss]

Ich habe einen Stack-Überlauf beim beenden der Anwendung.

Ich habe bei allen meinen WM_DESTROY Messagen Break Points gesetzt und nochmal genau geschaut ob hier
durch ein erneutes Destroy in welcher Form auch immer WM_DESTROY abermals aufgerufen wird.
Das ist nicht der Fall.

Der Compiler geht ins CPU Fenster und das wars. (Bin kein ASM Freak so das ich daraus schlau werden könnte)
Was muss ich beachten bzw. kann ich noch einstellen in den Debugger Option so das ich den Fehler lokalisieren kann.

gruss

[himitsu]

Na ja, in dem Fall ist der Aufruf-Stack (StackTrace) die erste Anlaufstelle, wo du reinschauen kannst/solltest.

Schön weit runter scrollen und mal nachsehn, was für Prozeduren vorher aufgerufen wurden.


Der Stack muß nicht unbedingt durch zu viele Prozeduraufrufe überlaufen.
Es kann auch durch zu viele und/oder zu große lokale Variablen passieren, welche ebenfalls da dauf landen.

[EWeiss]

Ach du meinst in dem Fenster Aufruf Stack?
wenn das so ist dann oops.. Ist wohl was spät heute.

EDIT:
:00406544 MakeErrorMessage + $48 bleibt er stehn 1 zeile
und die letzten zeilen

:77010133 ntdll.KiUserExceptionDispatcher + 0xf
:7705b63d ; ntdll.dll
:7705b60f ; ntdll.dll
:77010133 ntdll.KiUserExceptionDispatcher + 0xf
:004066a9 @Halt0 + $85
:76ac336a kernel32.BaseThreadInitThunk + 0x12
:770392b2 ntdll.RtlInitializeExceptionChain + 0x63
:77039285 ntdll.RtlInitializeExceptionChain + 0x36

Werde ich auch nicht schlau draus.

Zitat:

was für Prozeduren vorher aufgerufen wurden

Kann ich in dem Fenster nicht sehen.

Das ist ein sehr seltsames verhalten..
Meine Vorgehensweise.

Start 1
1.Starte Anwendung.
2. Starte mein Spectragram über Menü
3. Schließe das Spectragram über Menü
4. Starte es erneut auch über das Menü
5. Beende die Anwendung wenn beide Fenster offen sind. (X-Button)
Keine Probleme.

Start 2
1.Starte Anwendung.
2. Starte mein Spectragram über Menü
3. Beende die Anwendung wenn beide Fenster offen sind. (X-Button)
Stack Überlauf.

Start 3
1.Starte Anwendung.
2. Starte mein Spectragram über Menü
3. Beende die Anwendung wenn beide Fenster offen sind. (Über das Menü.. Beenden)
Keine Probleme

Kann es irgendwo nicht sein.

gruss

[himitsu]

Das sind schon die Namen der "letzten" aufgerufenen Prozeduren.
Scheint so, als wenn der in 'ner Exceptionbehandlung wieder 'ne Exception auslöst?

Als Erstes erkennt man die "Schleife", wenn man 'ne Wiederholung sieht ... immer wieder eine/mehrere "gleiche" Aufrufe hintereinander.

Das Hauptproblem ist, dass Delphi den Stacktrace nicht bis zum Ende Anfang auflistet, sondern nach einer gewissen Anzahl einfach stillschweigend aufhört.
Ist auch OK, aber die "Trottel" hätten dann wenigstens einen "lade mehr" oder "lade alles"-Knopf einbauen sollen.

Du kannst da nur versuchen "vorher" einzusteigen.
z.B. in OnClose/OnCloseQuery/OnDestroy deiner Form einen Haltepunkt und dann versuchen mit F7/F8 weitergehen, bis du irgendwann in die Schleife rein kommst (in den ersten paar Durchläufen reicht der Stacktrace dann noch weit genug zurück.

Oder du gehst in den aktuellen Stacktrace, suchst dir einen der Aufrufe aus und setzt da einen Haltepunkt drauf. (Doppelklick im Stacktrace und dann im Delphi- oder Assemblercode den Haltepunkt rein)
Dann beenden (Strg+F2) und nochmal neu versuchen.
Der Haltepunkt wird nun schon im ersten Durchlauf anhalten und der Stacktrace reicht dann hoffentlich auch weit genug zurück, damit man eine bessere/eigene Prozedur findet, die den Fehler eventuell ausgelöst hat.
Problem ist dabei, dass der Haltepunkt auch schon während der Laufzeit anspringen könnte (falls die Procedur unglücklich öfters aufgerufen wird)
* nochmal mit einem anderen Haltepunkt versuchen
* oder den Haltepunkt "deaktivieren" (nicht löschen), das Programm starten lassen und dann kurz vorm Beenden ihn wieder aktivieren
PS: Es gibt auch Haltepunktgruppen > man kann den Haltepunkt deaktivieren und gibt bei ihm eine Gruppe an (einfach einen Namen wählen), legt noch einen Haltepunkt z.B. ins OnClose und gibt beim ihm in den "weiteren" Haltepunkteigenschaften bei "Gruppe aktivieren" diese Gruppe an > kommst's Programm beim zweiten Haltepunkt vorbei, wird der erste Haltepunkt aktiviert und hält beim nächsten Mal an

[EWeiss]

Danke für die ausführlichen Infos.

Seltsam ist folgendes.

Aus der Anwendung
Vom Menü aus beendet..

Delphi-Quellcode:

IDM_Close:
  DestroyWindow(MainHandle);

Aus der DLL
Vom X Button beendet..

Delphi-Quellcode:

  case LoWord(wP) of
    ID_CLOSE:
    begin
      // Anwendung beenden
      DestroyWindow(WinHandle);
      Result := True;
      Exit;
    end;

Beide Funktionen führen ein und die selben Funktionen aus.
Anwendung wird beendet

Delphi-Quellcode:

    WM_DESTROY:
      begin
        if gnAudioChannel <> 0 then
          BassCloseChannel;

        if not INISave then
          SaveINI;

        PostQuitMessage(0);
        Result := 1;
        exit;
      end;

gut und die darauffolgenden Funktionen nach GetMessage.
Ich ändere nichts zwischen den einzelnen Start Ausführungen und trotzdem tritt so ein seltsames verhalten auf.

Ich werde mal schauen ob ich mich da durchbeißen kann.

gruss

[EWeiss]

Irgendwie bin ich jetzt echt .. sorry angepis..

Das Problem liegt an der Namensgebung und tritt nur bei einem Skin auf.
Folder(Energy) nach Energys oder anderen beliebigen Namen umbenannt das Problem ist weg.

Das kann es irgendwo nicht sein.
So ein Problem mit Delphi hatte ich vorher noch nie.
Wie kann das jetzt mit einem Stack Überlauf zusammen hängen.

Habe alles gemacht Bilder ausgetauscht usw.. was halt so geht.
Das umbenennen des Namen hat es dann gebracht aber warum ??
Ich will den nicht verändern.

EDIT:
Ohne den Ordner umzubenennen bekomme ich das Problem nicht behoben.
Keine Ahnung was das soll.
Der Name des Ordners findet im Code selbst absolut keine Verwendung daher wundert es mich das es trotzdem Einfluss darauf hat.
Ne, ne, ne.
Da bekommt man die Krise.


gruss

[jaenicke]

Mit den vorliegenden Informationen wird dir niemand sagen können woran das liegt.

Du benutzt doch dabei eine DLL, oder? Liegt die in der gleichen Projektgruppe und werden beide Projekte mit aktivierten Debuginformationen direkt in das Zielverzeichnis kopiert?

Denn nur so bekommst du Projekt übergreifend ordentliche Stacktraces.

MakeErrorMessage ist deine eigene Routine, oder? Dort kannst du ja einen Haltepunkt setzen.

Hast du irgendwelche Exceptions unterdrückt, so dass Delphi dort beim Debuggen nicht anhält?

[EWeiss]

Zitat von jaenicke:

Mit den vorliegenden Informationen wird dir niemand sagen können woran das liegt.

Die Frage ist nur welche Informationen sind von nöten?

Zitat:

Du benutzt doch dabei eine DLL, oder? Liegt die in der gleichen Projektgruppe und werden beide Projekte mit aktivierten Debuginformationen direkt in das Zielverzeichnis kopiert?

Ja DLL und Exe im gleichen Pfad.

Zitat:

MakeErrorMessage ist deine eigene Routine, oder? Dort kannst du ja einen Haltepunkt setzen.

Nein ist nicht meine Routine ist die von Delphi welche man im Aufruf-Stack Fenster zu sehen bekommt.

Zitat:

Hast du irgendwelche Exceptions unterdrückt, so dass Delphi dort beim Debuggen nicht anhält?
Denn nur so bekommst du Projekt übergreifend ordentliche Stacktraces.

Nein alle sind eingeschaltet und werden vom Debugger verwaltet.

Die Meldung die ich jetzt bekomme ist diese (Aufruf-Stack Fenster)

:002f1242 TInterfacedPersistent._Release + $12
:00409dd3 @IntfClear + $13
:004062e0 FinalizeUnits + $40
:004066a9 @Halt0 + $85
:7596336a kernel32.BaseThreadInitThunk + 0x12
:77d592b2 ntdll.RtlInitializeExceptionChain + 0x63
:77d59285 ntdll.RtlInitializeExceptionChain + 0x36

Das sind die einzigen.
Diese kommen aber nicht wenn ich den Folder umbenenne wohlbemerk mit gleichen Code.
Das kann es aber doch nicht sein.

gruss

[hoika]

Hallo,
du arbeitest also mit Interfaces (?).

eine der Interface-Variablen wurde bereits von Dir freigegeben,
und jetzt versucht Delphi das auch noch mal.

Das hatte ich letztens auch.
Da half nur das explizite nil-Setzen.

Das finnalize kannst du Debuggen, wenn du auf das end des Projektes
einen Breakpoint setzt und dann F7 drückst.

[p80286]

Zitat von EWeiss:

Diese kommen aber nicht wenn ich den Folder umbenenne wohlbemerk mit gleichen Code.
Das kann es aber doch nicht sein.

Klingt für mich nach "selbstmodifizierendem Code". Ist der Folder-Name der den Fehlerverursacht vllt. Länger und Überschreibt ggf. eine Adresse? Bereichsprüfung hast Du eingeschaltet?

Gruß
K-H