AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Sprachen und Entwicklungsumgebungen Sonstige Fragen zu Delphi FastMM Memory Leaks : Lesen und verstehen von Stacktrace
Thema durchsuchen
Ansicht
Themen-Optionen

FastMM Memory Leaks : Lesen und verstehen von Stacktrace

Ein Thema von taveuni · begonnen am 8. Sep 2014 · letzter Beitrag vom 16. Sep 2014
Antwort Antwort
pertzschc

Registriert seit: 29. Jul 2005
Ort: Leipzig
318 Beiträge
 
Delphi 12 Athens
 
#1

AW: FastMM Memory Leaks : Lesen und verstehen von Stacktrace

  Alt 15. Sep 2014, 10:00
Einverstanden. Aber dann müsste die Anzahl Instanzen im memory.log von FastMM doch hochgezählt werden. Und das ist eben nicht der Fall!
Kannst Du den Quellcode Deines Service posten? Irgendwo passiert es dort, auch wenn der FastMM es nicht mitbekommt. Oder wie vermutet ausserhalb (DLL)...
Christoph
  Mit Zitat antworten Zitat
taveuni

Registriert seit: 3. Apr 2007
Ort: Zürich
542 Beiträge
 
Delphi 11 Alexandria
 
#2

AW: FastMM Memory Leaks : Lesen und verstehen von Stacktrace

  Alt 15. Sep 2014, 10:18
Kannst Du den Quellcode Deines Service posten? Irgendwo passiert es dort, auch wenn der FastMM es nicht mitbekommt. Oder wie vermutet ausserhalb (DLL)...
Christoph
Leider nein. Auszüge davon ja - aber das ist sowieso sinnfrei. Glaubst Du - Du könntest nur durch Code Review das Problem erkennen? Ich habe schon mehrere meiner Meinung nach kritische Vorgänge isoliert (so a la Unittest) und diese unabhängig getestet. Ohne Ergebnis. Grob umrissen läuft es so:
- Es gibt einige Threadpools
- Ein Pool holt einzelne Images von Netzwerkkameras via HttpRequest
- Beim beenden des Jobs wird ein Objekt erzeugt in welchem ein TJpegImage und ein TBitmap32 erzeugt wird diese beiden Assignen das OriginalImage des HttpRequests.
- Das Originalimage wird freigegeben.
- Im Workerthread der Objekterkennung werden nun wilde Sachen gemacht. Am Ende werden die beiden erzeugten Objekte auch wieder freigegeben.

Da kann es sowieso nicht liegen da es HD Bilder sind und der Effekt nur mit 64 Kameras im 3 Sekunden Intervall überhaupt in nützlicher Zeit erkennbar ist. In einem anderen Service logge ich den Gesamtspeicherverbrauch des betroffenen Services. Ich sehe das ein steigen des Memorys Z.B in fünf Minuten schrittweise von 86 auf 89MB. Dann nächste Messung 87 - nach 5 Minuten schrittweise auf 92. Nächste Messung 89.... So geht das rauf und runter. Nur in der Tendenz leider rauf.

Wenn du mit Inline Hooks vertraut bist, könntest du einfach mal die genannten APIs hooken und dann jeweils auch die Rücksprungadresse vom Stack loggen. Eventuell findest du ja darüber den Übeltäter.
Leider momentan (noch) nicht. Kann es sein dass ich mit AQ Time weiterkäme? Wobei das ja preislich für dieses eine Ding.. Andererseits wenn ich Tage und Wochen aufwende....
Die obige Aussage repräsentiert meine persönliche Meinung.
Diese erhebt keinen Anspruch auf Objektivität oder Richtigkeit.

Geändert von taveuni (15. Sep 2014 um 10:20 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Zacherl
Zacherl

Registriert seit: 3. Sep 2004
4.629 Beiträge
 
Delphi 10.2 Tokyo Starter
 
#3

AW: FastMM Memory Leaks : Lesen und verstehen von Stacktrace

  Alt 15. Sep 2014, 10:24
FastMM kann ja logischerweise nur Memory Manager interne Speicherreservierungen loggen, sprich: GetMem, FreeMem, New, Dispose und so weiter. Deshalb bin ich mir zu 99% sicher, dass irgendwo per WinAPI direkt Speicher alloziiert wird.

Es gibt doch bestimmt noch massenhaft "externe" Tools, welche die genannten WinAPIs überwachen und profilen können (Das vielleicht: http://winleak.sourceforge.net/).
Projekte:
- GitHub (Profil, zyantific)
- zYan Disassembler Engine ( Zydis Online, Zydis GitHub)

Geändert von Zacherl (15. Sep 2014 um 10:26 Uhr)
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#4

AW: FastMM Memory Leaks : Lesen und verstehen von Stacktrace

  Alt 15. Sep 2014, 10:26
Welche Windows Resourcen werden alloziiert? Google mal nach MemProof 0.948, das ist noch umsonst und könnte diesbezüglich Fragen beantworten (wenn FastMem das nicht macht)

Wäre es denkbar, das die Threads abbrechen und deshalb 'am Ende' keine Bilder freigegeben werden. Manchmal zumindest. Natürlich müsste man das in FastMem sehen, aber ....
  Mit Zitat antworten Zitat
taveuni

Registriert seit: 3. Apr 2007
Ort: Zürich
542 Beiträge
 
Delphi 11 Alexandria
 
#5

AW: FastMM Memory Leaks : Lesen und verstehen von Stacktrace

  Alt 15. Sep 2014, 12:25
Leider scheinen weder WinLeak noch memproof mit dem 64bit Betriebssystem klarzukommen.
Die obige Aussage repräsentiert meine persönliche Meinung.
Diese erhebt keinen Anspruch auf Objektivität oder Richtigkeit.
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#6

AW: FastMM Memory Leaks : Lesen und verstehen von Stacktrace

  Alt 15. Sep 2014, 13:55
Immer dieses 64bit
  Mit Zitat antworten Zitat
Der schöne Günther

Registriert seit: 6. Mär 2013
6.212 Beiträge
 
Delphi 10 Seattle Enterprise
 
#7

AW: FastMM Memory Leaks : Lesen und verstehen von Stacktrace

  Alt 15. Sep 2014, 15:47
Und jetzt?
  Mit Zitat antworten Zitat
taveuni

Registriert seit: 3. Apr 2007
Ort: Zürich
542 Beiträge
 
Delphi 11 Alexandria
 
#8

AW: FastMM Memory Leaks : Lesen und verstehen von Stacktrace

  Alt 15. Sep 2014, 15:52
Ich habe per Zufall (vielleicht) etwas gefunden. Der Service läuft jetzt beim Kunden. Ich melde mich morgen wieder. Wenn es das war möchte ich dann von Euch wissen weshalb.
Die obige Aussage repräsentiert meine persönliche Meinung.
Diese erhebt keinen Anspruch auf Objektivität oder Richtigkeit.
  Mit Zitat antworten Zitat
taveuni

Registriert seit: 3. Apr 2007
Ort: Zürich
542 Beiträge
 
Delphi 11 Alexandria
 
#9

AW: FastMM Memory Leaks : Lesen und verstehen von Stacktrace

  Alt 16. Sep 2014, 06:57
O.K. Das war ja einfach Das ist der Verusacher:
Delphi-Quellcode:
procedure TDetectionCore.CopyPictures(PicFrom, PicTo: String);

function CopyFileEx(const ASource, ADest: string; ARenameCheck: boolean = false): boolean;
var
  sh: TSHFileOpStruct;
begin
  // so was hat offensichtlich gefehlt. Das war im Original nicht drin.
{--->} FillChar(sh,SizeOf(sh),0); {<---}
  sh.wFunc := FO_COPY;
  sh.pFrom := PChar(ASource + #0);
  sh.pTo := PChar(ADest + #0);
  sh.fFlags := fof_Silent or fof_MultiDestFiles;
  if ARenameCheck then
    sh.fFlags := FOF_NOCONFIRMATION;
  Result:=ShFileOperation(sh)=0;
end;

begin
  FFileLock.Enter;
  Try
    if ForceDirectories(ExtractFilePath(PicTo)) then
    begin
      if not CopyFileEx(PicFrom, PicTo, True) then
        LogError('could not copy File:%s to:%s',[PicFrom,PicTo]);
    end
    else
      LogError('could not create directory: %s',[ExtractFilePath(PicTo)]);
  Finally
    FFileLock.Release;
  End;
end;
Muss ich das einfach wissen? Vermutlich würde auch ZeroMemory gehen? Diese Struktur ist als Record definiert. Und der Record wird der Funktion ShFileOperation als const übergeben. Üble Sache. Müssen Records grundsätzlich so behandelt werden? Oder nur mit Windows eigenen Funktionen?

Nebenbei: Bevor ich auf das gekommen bin habe ich die Copyfunktion durch das ersetzt:
Delphi-Quellcode:
var
  mem: TMemoryStream;
begin
  FFileLock.Enter;
  Try
    mem:= TMemoryStream.Create;
    if ForceDirectories(ExtractFilePath(PicTo)) then
    begin
      mem.LoadFromFile(PicFrom);
      mem.SaveToFile(PicTo);
    end
  Finally
    mem.Free;
    FFileLock.Release;
  End;
Gibt es da eine Präferenz bezüglich Geschwindigkeit oder anderen Gesichtspunkten das Eine oder das Andere zu nutzen?

Auf jeden Fall: Ich danke Euch vielmals für Eure Hinweise. Besonders nachdem FastMM zufrieden war hätte ich nicht weiter gewusst.
Jetzt kann ich endlich aus dem Memory Loch wieder herauskriechen

Gruss Werner
Die obige Aussage repräsentiert meine persönliche Meinung.
Diese erhebt keinen Anspruch auf Objektivität oder Richtigkeit.
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:38 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-2025 by Thomas Breitkreuz