Stack überlauf

[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

[EWeiss]

Zitat:

Zitat von p80286 (Beitrag 1347228)

Zitat:

Zitat von EWeiss (Beitrag 1347225)

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

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.

Delphi-Quellcode:

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:

Zitat von EWeiss (Beitrag 1347230)

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.

[EWeiss]

Zitat:

Du meinst as TSkinPopupWindow, oder?

Ja richtig ;)
Habe es so eingetippt und nicht nachgedacht.

Wie man am Bild sehen kann (ein langer Name für den Folder und kein Problem.

Langer Ordner Name so heißt dann der Skin ;)

Ich habe damit keinerlei Probleme.
Das verstehe ich nicht.

Umbenannt ;)
Und es kracht.

gruss

[QuickAndDirty]

Ich weiß nicht ob ich eine hilfe sein kann, weil ja schon alle die über die Interna Delphis bescheid wissen geantwortet haben.
Aber ich hatte auch mal ein Problem mit namen in Delphi und vielleicht nimmt der Stacküberlauf ja in einem ganz trivialen Problem den Anfang.

Wegen der Message Queue soll man ja Formulare nicht mit Free zerstören sondern mit Release.
Ich habe die Erfahrung gemacht dass man obwohl man ein Formular mit Release zerstört hat nicht sofort danach wieder ein Formular mit selben namen erzeugen kann.
Es führt zu einer Exception. ...unique component name....bla
Hab nen globalen ID counter an alle Formular-Namen anhängen müssen und ne eigene Methode für Namensvergleiche geschrieben um dem Herr zu werden.

Kann es sein dass es irgendwo in deinem Projekt noch einen String "Energy" gibt der als Componentname Verwendung findet während des Abräumens der Anwendung? Vielleicht eine Liste von TCompoents oder so?

[hoika]

Hallo,

"Energy" darf der Ordner ja eh nicht heissen.

Das Wort ist doch für uns Trekkies reserviert ;)

[Sherlock]

Engage...oder eben Energie.

https://www.youtube.com/watch?v=3jd1Ih8EUmw

Ausser natürlich: https://www.youtube.com/watch?v=bUtz...utu.be&t=8m20s

Sherlock

[p80286]

Mal so ins Blaue
a) Vergrößere den Stack, dann gibt's keine Fehlermeldung mehr (nicht ernst gemeint)
b) Verkleinere den Stack, dann knallt es früher, und vllt. an der richtigen Stelle.
c) Was ist der Unterschied zwischen Energie/y und den anderen Skins abgesehen vom Namen? wird da etwas rekursiv aufgerufen?

Und natürlich ganz banal, der Stack läuft über wenn man zuviel darauf schiebt.

Ich weiß jetzt auch nicht mehr ob "Stack Frame" Dir beim Finden des Fehlers hilft. Irgendwann vor langer Zeit, war das auf jeden Fall empfehlenswert.

Gruß
K-H

[EWeiss]

Zitat:

Vielleicht eine Liste von TCompoents oder so?

Der Name hat keinerlei Bezug zum Quelltext wenn man davon absieht das ich rekursive im Skin Ordner nach den Namen Anwendung.ske suche.

Also wenn diese Soundmachine.exe heißt suche ich nach dem Konfigurationsfile Soundmachine.ske
Wenn gefunden wird der Name des Folder als Skin identifiziert und damit zum Menu addiert.

Daher verstehe ich den Bezug nicht warum nur wegen der Namensgebung ein Überlauf stattfindet.

Zitat:

Und natürlich ganz banal, der Stack läuft über wenn man zuviel darauf schiebt.

Dann müsste er eher bei Energys überlaufen anstatt bei Energy.
Klar kann ich einen anderen Namen verwenden nur das ist nicht der sinn der Sache.

Zitat:

Das Wort ist doch für uns Trekkies reserviert

Genau darauf ist er ja auch ausgelegt.


gruss

[Uwe Raabe]

Kannst du mal ausprobieren, ob es an dem String Energy liegt, oder ob auch ein anderer Text mit gleicher Länge das Problem zeigt?