Zugriffsverletzung beim Zerstören der TIniFile-Instanz

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

Zitat von Fritzew (Beitrag 1481931)

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:

Zitat von jaenicke (Beitrag 1481924)

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

Ja, das Problem mit den Haltepunkten :D 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 :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:

{$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?!

[Poelser]

Zitat:

Zitat von TheSledgeHammer (Beitrag 1481990)

Muss die dann auch noch zur FullDebug-DLL mit dazu gelegt werden?!

Nein, muss sie nicht. Die wird nur zum Compilieren gebraucht, um die dort gemachten Einstellungen in die Exe einzucompilieren.

LG aus dem hohen Norden, Edmund

[TheSledgeHammer]

Ok, d.h. ich hab offenbar tatsächlich keine MemLeaks? :shock:

[himitsu]

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;

[TheSledgeHammer]

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: