![]() |
AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz
Zitat:
|
AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz
FreeAndNil kopiert nur den Objektzeiger
und setzt vor dem Free die originale Variable auf NIL. (erspart sich so ein TryFinally)
Delphi-Quellcode:
Ohne ARC, passiert mit der Objekt-Referenz nichts. (das kopieren der Variable macht nichts, außer den Pointer/Integer zu kopieren)
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; 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. |
AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz
Liste der Anhänge anzeigen (Anzahl: 1)
Zitat:
Wie sieht denn der Stacktrace aus bzw. was passiert, wenn du in das Free hinein debuggst? Eigentlich sollte dort Self = nil sein und somit kein Code ausgeführt werden: Anhang 53590 Bist du sicher, dass nicht FastMM oder ähnliches aktiv ist? Denn die prüfen so etwas und lösen dann eine Exception aus. |
AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz
Zitat:
|
AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz
Zitat:
Bei FastMM passiert (eben getestet) in der Tat nichts. |
AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz
Ich tippe schlichtweg auf Test-Case-Error. Ich kann mir nicht vorstellen, dass mein Beispiel in irgendeiner Delphi-Version (eventuell nach Anpassung der uses-Anweisung) eine Exception auslöst.
|
AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz
Sind da vielleicht noch Threads am Arbeiten, die irgendein Problem haben (und es nur so aussieht, als läge es am TIniFile)?
|
AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz
Zitat:
|
AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz
Zitat:
|
AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz
Zitat:
|
AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz
Hast du einmal einen Haltepunkt auf das Destroy der TIniFile Klasse gesetzt? Dann siehst du dort vielleicht mehr...
|
AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz
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. |
AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz
Zitat:
|
AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz
Zitat:
|
AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz
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.) |
AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz
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 :lol: 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
Delphi-Quellcode:
eingestellt. Auch hier gilt wieder: nicht beim Aufrufer.
{$IFDEF DEBUG}ReportMemoryLeaksOnShutdown := true;{$ENDIF}
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?! |
AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz
Zitat:
LG aus dem hohen Norden, Edmund |
AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz
Ok, d.h. ich hab offenbar tatsächlich keine MemLeaks? :shock:
|
AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz
Kommt drauf an, was du als Memory-Leck ansiehst.
Delphi-Quellcode:
procedure TForm1.FormCreate(Sender: TObject);
begin ReportMemoryLeaksOnShutdown := True; // oder in der DPR gemacht end; procedure TForm1.Button1Click(Sender: TObject); begin for var i := 0 to 1000 do TComponent.Create(Self); // MemoryLeak zu Laufzeit, aber bei ProgrammEnde weg (da, wo ReportMemoryLeaksOnShutdown nachsieht) end; procedure TForm1.Button2Click(Sender: TObject); begin for var i := 0 to 1000 do TComponent.Create(nil); // MemoryLeak bis zum Ende end; |
AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz
Ja ok, das ist klar, das ist auch kein tatsächlicher Memory Leak, da der Owner sich ja um das Aufräumen kümmert. Ein TInitFile hat keinen Owner, ergo sollte man es nach dem Erzeugen auch wieder freigeben, sonst gibt es einen Memory Leak. Und in meinem Fall gibt's dann sogar noch eine AV oben drauf :roll:
|
AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz
Zitat:
Dann weißt Du zumindest, ob sowas korrekt gefunden wird. |
AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz
Wenn FastMM auch nichts findet, bleibt nur mit Logs zu analysieren... z.B. den Speicher des Objekts nach der Erzeugung als Dump loggen und dann bei der Freigabe, ...
Das ist nicht schön, aber solche Fehler sind leider nicht so einfach zu finden. |
AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz
Das volle FastMM kann bei Speicherfreigabe den Speicher überschreiben (mit einem Muster markieren)
so würde z.B. eine Doppelfreigabe oder ein Zugriff nach der Freigabe auffallen. -> Man müsste nur noch das entgültige Freigeben ein bissl verzögern, damit auch freigegebener und inzwischen wiederverwendeter Speicher in diese Prüfung fallen. Gegen sowas wie Buffer-Overrun oder komplett falsche/ungültige Zeiger kann man sich aber nicht wirklich wehren. Und ja, möglich wäre es viele Wichtige oder gleich alle Speicheranforderungen/-freigaben in ein Log schreiben zu lassen. Wenn es dann später knallt, dann kann man z.B. schauen was vorher alles an der Stelle mal war. |
AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz
Zitat:
Ausgelöst in TFormDynamicSearchDialog.LoadIni durch die Zeile "tbExpert.Click;". |
AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz
Ja, eines dieser Fehlerprotokolle zeigt eine Rekursion, da geb ich dir Recht. Ich hab aber genau so viele Berichte mit Rekursion, wie solche, bei denen der Fehler nicht rekursiv geschieht, sondern wo es direkt beim ShowModal knallt. Ich hab - zugegeben - nicht geschaut, welchen Bericht ich da jetzt genommen hab, weil die Zeile, wo es knallt, exakt identisch ist. Ich kann dir aber beim besten Willen nicht sagen, warum in diesem Dump eine Rekursion enthalten ist... LoadIni() wird nur einmal aufgerufen...
|
AW: Zugriffsverletzung beim Zerstören der TIniFile-Instanz
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:21 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz