XE7, Eurekalog7, MadExcept, AV

[haentschman]

Hallo alle...

Ich hätte gern mal ein Problem...:P

Wir haben eine Anwendung welche sich sowohl über die IDE als auch als EXE normal beendet. Bindet man den Eurekalog oder den MadExcept ein, taucht eine AV auf. :roll: Diesmal dann auch im Debugger. Beide haben aber einen völlig unterschiedlichen Callstack. Gemeinsam haben alle den "Auslösepunkt" in der System.pas (Bild1, Bild2).

Mit einem Testprogramm konnte ich einen "Auslöser" ausmachen. Eine eigene Combobox mit Panel auf welchem dynamisch Checkboxen plaziert werden. Bei der Freigabe des Panels und dem damit verbundenem Abräumen der plazierten Controls kommt es zu besagter AV in System.pas.
Aaaaber: Hier erhielt ich auch nachfolgende AV´s aus der Forms.pas. Und das kann ich mir nun wirklich nicht vorstellen. Deshalb tippe ich nicht wirklich auf unseren Code.

Dann hätten wir noch was Witziges in diesem Zusammenhang. Diese Anwendung arbeitet auch mit Nexus. Ohne Eurekalog ganz normal. Mit Eurekalog fliegt sie in der Data.DB mit einer AV weg. Erstaunlicherweise auch im System.pas. :roll: (Bild3)

Hat jemand mit Eurekalog in Kombination mit XE7 ähnliches erlebt? Wir versuchen die Ursache einzugrenzen und wissen noch nicht wirklich ob es am eigenen Code liegt oder an den Erweiterungen.

Für Tipps sind wir dankbar :P Für die Lösung gibts ein Bier auf den nächsten DT. Einverstanden? :P

[Uwe Raabe]

Kannst du das Testprogramm anhängen?

[haentschman]

Leider nein. :? Beinhaltet Code / Controls von uns.

[himitsu]

Vom Stacktrace her:
Es gibt eine Objektinstanz, welche eine Interface-Variable als Feld besitzt.
Und beim Freigeben knallt es, beim Aufräumen der Interface-Variable.

Ihr könntet es mal mit FastMM im FullDebugMode versuchen. (mit und ohne Eurekalog/MadExcept)

[stahli]

Ich hatte kürzlich hier eine ähnliche Fragestellung: http://www.delphipraxis.net/184135-e...erletzung.html

... und als Ergebnis lediglich in Erwägung gezogen, irgendwann mal ein EL-Update zu machen.
Aber wenn MadExcept den gleichen Fehler aufzeigt ist man ja noch ratloser.

Es gibt da noch einen weiteren Profiler (irgendwie ...DDD... ich weiß nicht mehr genau) von einem deutschen Entwickler. Vielleicht gibt der ja noch andere Infos an.


@himitsu

Interfaces waren bei mir auch im Spiel, obwohl ich die Referenzählung ausgeschaltet hatte und da eigentlich kein Problem mehr bestanden haben dürfte.

[himitsu]

Du kannst die Referenzzählung nicht abschalten.

Die Funktionen werden dennoch aufgerufen, egal was man "intern" macht.
Abgeschaltet wird es nur bei [Weak]-Referenzen, was es für Windows (noch) nicht gibt. (nur im NextGen)

In anderen Sprachen werden Weak-Referenzen automatisch nil, wenn das Objekt freigibt ... sowas gibt es als Komponenten auch für Delphi.
In Delphi wird [Weak] einfach nur zu einem "ungültigem" Pointer.

[stahli]

Nachtrag:

Ich hatte _AddRef und _Release selbst implementiert, ohne dass Sie etwas mit dem Objekt tun, also dieses nicht freigeben.
Insofern war ich der Meinung, dass das Objekt wie ein einfaches Objekt reagiert und gemanaged wird.

Kann natürlich sein, dass da dennoch etwas im Hauptspeicher gemacht wird, das EurekaLog dann bemeckert. Ich bin allerdings nicht in der Lage, das nachzuvollziehen.

Solche Probleme scheinen aber jedenfalls irgendwie von Interfaces verursacht zu werden.

[Stevie]

Das sieht - wie himitsu auch schon anmerkte - sehr stark nach einer Interface Referenz auf ein bereits freigegebene Instanz aus.

FastMM FullDebug mit use after Free Detektion und ab gehts.

[Uwe Raabe]

Zitat:

Zitat von stahli (Beitrag 1292502)

Ich hatte _AddRef und _Release selbst implementiert, ohne dass Sie etwas mit dem Objekt tun, also dieses nicht freigeben.
Insofern war ich der Meinung, dass das Objekt wie ein einfaches Objekt reagiert und gemanaged wird.

Das verhindert aber nicht, daß der Compiler die Aufrufe für _AddRef und _Release erzeugt, die nach Freigabe der Instanz dann natürlich ins Leere laufen oder sonstwohin.

[himitsu]

Zitat:

Zitat von stahli (Beitrag 1292502)

Ich hatte _AddRef und _Release selbst implementiert, ohne dass Sie etwas mit dem Objekt tun, also dieses nicht freigeben.

Ja, wenn man dort die Freigabe des Objektes nicht implementiert,
dann wird das Objekt nicht durch die Interface-Referenzen freigegeben.

Man muß aber aufpassen, daß alle Interface-Referenzen auf nil stehen/überschrieben wurden, "bevor" das Objekt freigegeben wird.
Ansonsten zeigt die Variable auf "Schrott" und es knallt, wenn Delphi versucht diese Interface-Referenz aufzuräumen. (inkl. Aufruf von _Release)

Genau dafür gibt es nun endlich die besagten [Weak]-Referenzen (aber noch nicht im Windows-Compiler :cry:)

[haentschman]

Danke für die zahlreichen Ideen. :thumb:

Zitat:

Das sieht - wie himitsu auch schon anmerkte - sehr stark nach einer Interface Referenz auf ein bereits freigegebene Instanz aus.

FastMM FullDebug mit use after Free Detektion und ab gehts.

...eure Idee für die Ursache hatte ich auch schon. Den FastMM probiere ich dann mal.

[stahli]

...zu DDD: jetzt will ich der Vollständigkeit halber mal noch liefern:

http://www.delphipraxis.net/172214-d...-profiler.html
https://www.youtube.com/watch?v=Rhnh_QKbVFQ


@himi

In meinem Fall ging es wohl nicht um eine hängengebliebene Interfacereferenz.
Aber ich will das jetzt auch nicht mehr weiter nachverfolgen.

[haentschman]

:cheer:Moin...:P

Zitat:

FastMM FullDebug mit use after Free Detektion und ab gehts.

Ich dachte beide sind Options in der inc. :roll: Kannst du mal erklären wie das after Free Detection eingestellt wird? FullDebugMode ist klar.

Danke.

Nachtrag:
Fehler gefunden. :cheer:

ohne EL
1. normal ReportMemoryLeaksOnShutdown -> negativ
2. FastMM4 FullDebugMode -> negativ

mit EL
3. normal ReportMemoryLeaksOnShutdown -> AV beim Beenden und Speicherloch
4. FastMM4 FullDebugMode -> AV beim Beenden

mit EL ohne EL Memory Manager
5. keine AV und keine Leaks.

Ihr könnt mich gern berichtigen. Ich denke der Speichermanager des Eurekalog ist dafür verantwortlich.

:? Zu früh gefreut. Auch der FullDebugMode kracht mit AV und Speicherlöchern. (Hatte vorhin die DLL im verkehrten Ordner) Das Deaktivieren des Memory Managers verhindert nur die Prüfung. Die Preisfrage ist, ob man das ignorieren kann...

[Stevie]

Klar, man kann alle Bugs ignorieren - genau wie nen Handwerker, der einfach irgendwo drüber spachtelt oder streicht.
Wenn du dann nach nem Jahr Flecken anner Wand hast, fängt der Ärger an.

Genau deshalb kracht die FastMM (und vermutlich auch der EL Speichermanager). Die sind extra so eingestellt.

[jaenicke]

Es gibt mehrere Ansätze. Einmal kannst du versuchen im CleanupInstance oder weiter höher im Stacktrace eine Stelle zu finden, an der ClassName noch einen gültigen Wert enthält. Das dann im Debugger per Haltepunkt-Eval ausgeben lassen und durchlaufen lassen. Dauert dann, aber irgendwann kommt die Exception und man kann schauen, ob der ClassName direkt vorher einen Wert hatte.

Wenn ja, kannst du daraus evtl. schon etwas ableiten.

Wenn nein oder du keinen gültigen Klassennamen mehr bekommst, gibt es Hilfsmittel wie DDDebug, aber mit Bordmitteln kannst du auch einfach z.B. im TObject.AfterConstruction jeweils die Self-Speicheradresse plus ClassName loggen. Die Self-Adresse kannst du dann wiederum im CleanupInstance abgreifen und im Log suchen.
Wenn du dann den Klassennamen hast, kannst du auch den Stacktrace mitloggen lassen, wenn du noch keine andere Idee hast.

Das sind relativ langwierige Methoden, die dafür sehr einfach sind. Es gibt auch kompliziertere Vorgehensweisen, denn der Speichermanager von FastMM hat z.B. auch Infos über die Objekte, aber das braucht etwas mehr Erklärung.

[haentschman]

Moin...

danke nochmal. :P Ich bin inzwischen aus der Nummer raus. Das Problem betrifft die Abteilung welche die Komponente erstellt hat. Die kümmern sich nun drum. Ich sollte ja eh nur Info´s sammeln. Ich leite das dann mal weiter...:thumb: