Zugriffsverletzung beim Zerstören der TIniFile-Instanz

[himitsu]

Ob Free oder FreeAndNil macht keinen Unterschied, denn FreeAndNil ruft auch nur Free auf.
Außer dass FreeAndNil eigentlich NilAndFree heißen müsste, da es zuerst die Variable auf NIL setzt und danach Free aufruft.

Das Einzige, wo FreeAndNil anders arbeiten könnte, als wie Free, das wäre im Nextgen, wo dabei auch noch die Referenzzählung mitspielen würde,
wobei dort Free ja eigentlich garnichts macht. (dessen Inhalt ist dort deaktiviert)

[Codehunter]

Zitat von himitsu:

Ob Free oder FreeAndNil macht keinen Unterschied, denn FreeAndNil ruft auch nur Free auf.
Außer dass FreeAndNil eigentlich NilAndFree heißen müsste, da es zuerst die Variable auf NIL setzt und danach Free aufruft.

Womöglich ist genau das der Punkt? Wobei, wenn ich mir die Quelle von FreeAndNil anschaue, dann tut das schon noch ein bissle mehr als das. Jedenfalls war es für mich immer von Vorteil, die Variable definiert auf nil zu setzen. Und ich bin mir nicht so ganz sicher, ob hier nicht noch ein wenig Compiler Magic ins Spiel kommt...

[himitsu]

FreeAndNil kopiert nur den Objektzeiger
und setzt vor dem Free die originale Variable auf NIL. (erspart sich so ein TryFinally)

Delphi-Quellcode:

Temp := VAR;  // mit ARC sind einfach die Zeilen 1 und 3 nutzlos und werden weggelassen
VAR := nil;
Temp.Free;

// statt

try
  VAR.Free;
finally
  VAR := nil;
end;

Ohne ARC, passiert mit der Objekt-Referenz nichts. (das kopieren der Variable macht nichts, außer den Pointer/Integer zu kopieren)

Und mit ARC wird effektiv nur die VARiable auf NIL gesetzt. (original würde die Variable kopiert, dabei AddRef/INC ausgeführt,
dann die alte Variable auf NIL gesetzt und somit ReleaseRef/DEC, und am Schluß Free, was aber im bei ARC garnichts macht)


PS: Das Application.FormCreate ist gegenüber dem TForm.Create das Selbe, wie FreeAndNil gegenüber einem Free.
Dort wird die Variable zuerst gesetzt, bevor Create ausgeführt wird. (eigentlich wird die Variable ja erst gesetzt, nachdem das Create fertig ist, was blöd ist, wenn eine Form-Referenz in der DFM vorkommt, oder jemand im Create oder einem Property-Setter so blöd ist und die globale Form-Variable benutzt, anstatt Self)
Und beim FreeAndNil wird eben die Variable gelöscht, bevor Destroy ausgeführt wird.

[TheSledgeHammer]

Zitat von Codehunter:

Zitat von himitsu:

Ob Free oder FreeAndNil macht keinen Unterschied, denn FreeAndNil ruft auch nur Free auf.
Außer dass FreeAndNil eigentlich NilAndFree heißen müsste, da es zuerst die Variable auf NIL setzt und danach Free aufruft.

Womöglich ist genau das der Punkt? Wobei, wenn ich mir die Quelle von FreeAndNil anschaue, dann tut das schon noch ein bissle mehr als das. Jedenfalls war es für mich immer von Vorteil, die Variable definiert auf nil zu setzen. Und ich bin mir nicht so ganz sicher, ob hier nicht noch ein wenig Compiler Magic ins Spiel kommt...

D.h. irgendwie sollte ich es mit FreeAndNil probieren, aber irgendwie auch nicht?

[jaenicke]

Hast du einmal einen Haltepunkt auf das Destroy der TIniFile Klasse gesetzt? Dann siehst du dort vielleicht mehr...

[Fritzew]

Stimmen die Callingconventions in der Dll und dem aufrufenden Programm?
Also cdecl oder stdcall?
Für mich sieht Dein Fehler ja nach einem kaputten Stack aus, das könnte das problem sein.

[TheSledgeHammer]

Zitat von Fritzew:

Stimmen die Callingconventions in der Dll und dem aufrufenden Programm?
Also cdecl oder stdcall?
Für mich sieht Dein Fehler ja nach einem kaputten Stack aus, das könnte das problem sein.

Ist alles CDECL.

[TheSledgeHammer]

Zitat von jaenicke:

Hast du einmal einen Haltepunkt auf das Destroy der TIniFile Klasse gesetzt? Dann siehst du dort vielleicht mehr...

Ja, das Problem mit den Haltepunkten Dieser Fehler tritt nur zur Laufzeit bei Releases auf. Offenbar nicht spezifisch an einem Rechner oder bei einem bestimmten Programm (aktuell verwenden 2 oder 3 Programme diese DLL) und auch nicht User-bezogen. Ich will es mal so formulieren: von 30 Mal, wo die DLL aufgerufen wird, knallt es 10 Mal. Ich erhalte ja dann von madExcept den Dump, den hatte ich ja auch schon mal gepostet. Und wie so häufig knallt es nie, wenn der Entwickler das probiert. Ihr glaub nicht, wie sehr ich mich angestrengt hab, diesen Fehler zu provozieren, damit der Debugger mir da an die Stelle springt...

[jaenicke]

Das spricht umso mehr für die bereits erwähnte Vermutung, dass der Speicher dort kaputt ist.

Hast du die DLL einmal mit FastMM und aktiviertem FullDebugMode kompiliert? Das könnte auch auf der Entwicklermaschine solche Fehler aufdecken. Oder auch wenn es knallt: Dann bekommst du evtl. Stacktraces von Erstellung und fehlerhafter Änderung des Speichers. (Du musst die FullDebugMode DLL von FastMM dann mitliefern.)

[TheSledgeHammer]

Also ich hab das jetzt eingerichtet. Und bei mir, wenn ich das auf dem Entwicklungsrechner laufen lasse, wird beim Shutdown offenbar nicht ein einziger MemLeak entdeckt. Das kann schon nicht sein Also irgendwo ist immer einer

Nur weiß ich nicht, was ich noch groß machen soll. FastMM4 ist als erste Unit im DLL-Projekt eingebunden. Muss das zusätzlich auch in die aufrufende Applikation mit rein? Zudem ist im DLL-Projekt
{$IFDEF DEBUG}ReportMemoryLeaksOnShutdown := true;{$ENDIF} eingestellt. Auch hier gilt wieder: nicht beim Aufrufer.

FastMM wurde so eingerichtet, dass der FullDebug-Mode aktiv ist. Allerdings würde ich hier gerne wissen, wo das gespeichert wird? Ich mein, es gibt da ne .inc-Datei, wo man das alles aktivieren kann. Muss die dann auch noch zur FullDebug-DLL mit dazu gelegt werden?!