Stack überlauf

[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.

[EWeiss]

Zitat:

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

Ich werde es mal versuchen.
Aber wie schon gesagt mein Problem kann\muss aber nichts mit meinem Code zu tun haben.
Denn wenn ich den Folder umbenenne habe ich das Problem nicht.
Und ich komme zum verrecken nicht darauf woran das liegt.

Trotzdem Danke für deinen Ratschlag werde mich da mal drangeben.

gruss

[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

[EWeiss]

Zitat von 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

Nein das ist ein ganz kurzer Name. "Energy"
Wenn ich den Folder nach "Was denn nun" umbenenne oder einfach nur ein S anhänge "Energys" funktioniert alles
und der Code läuft fehlerfrei durch.

Ich habe versucht die Interface hart zu beenden (ohne Referenzzähler) bringt aber auch nichts.

PopupWindow := ISkinPopupWindow;

Beim beenden dann

Delphi-Quellcode:

(PopupWindow as ISkinPopupWindow).Free
PopupWindow := Nil;

Aber das bringt alles nichts sobald ich den Namen verwende kracht es.
Ist schwierig bei solchen Voraussetzungen.

gruss

[jaenicke]

Zitat von EWeiss:

Delphi-Quellcode:

(PopupWindow as ISkinPopupWindow).Free
PopupWindow := Nil;

Du meinst as TSkinPopupWindow, oder?
Aber ob mit oder ohne Referenzzählung, das kann nicht funktionieren. Sobald noch irgendwo ein Interface auf dieses schon freigegebene Objekt existiert, wird beim Finalisieren der Anwendung darin das _Release aufgerufen. Ist das Objekt schon freigegeben, passiert das auf diesem schon freigegebenen Objekt. Im günstigsten Fall knallt es direkt, z.B. wenn FastMM eingebunden ist, im ungünstigsten zerschießt du den Speicher und es knallt ganz woanders.

Ein beliebtes Problem ist, dass ein Interface an eine DLL übergeben wird oder umgekehrt, aber beim Beenden nicht sauber wieder getrennt wird. Insbesondere kann ein Interface, das aus einer DLL kommt, in der Anwendung übrig bleiben, wenn die DLL entladen wird. Deshalb gibt es bei uns Shutdown-Prozeduren, in denen Listener usw. entfernt werden, so dass nach dem Entladen der DLLs keine Leichen übrig bleiben.

Eine andere Möglichkeit wäre, dass du irgendwo ein Objekt als Objekt und Interface parallel nutzt.

Solche Probleme kannst du mit FastMM aber oft schon direkt finden.