AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Sprachen und Entwicklungsumgebungen Sonstige Fragen zu Delphi Delphi Wie zuverlässig ist der MemoryLeak-Report von FastMM?
Thema durchsuchen
Ansicht
Themen-Optionen

Wie zuverlässig ist der MemoryLeak-Report von FastMM?

Ein Thema von Nuclear-Ping · begonnen am 11. Mär 2008 · letzter Beitrag vom 13. Mär 2008
Antwort Antwort
Seite 2 von 2     12   
Nuclear-Ping
(Gast)

n/a Beiträge
 
#11

Re: Wie zuverlässig ist der MemoryLeak-Report von FastMM?

  Alt 12. Mär 2008, 08:13
Ah, danke.

Stimmt, die wachsen langsam an. Zum Start warens 187, nach der 4. Liste inzw. 206 ... Er gibt auch während der Sendung immer mal wieder 1-2 frei, geht dann aber wieder auf 206 ... Grad bei 208 ... Also Tendenz scheint langsam aber sicher nach oben zu gehen.

"GDI" ist relativ unbekanntes Theretorium für mich. Hab den Begriff zwar schon zig mal gehört, aber direkt zu tun hatte ich damit noch nicht. Wie können da Leaks entstehen?
  Mit Zitat antworten Zitat
Dax
(Gast)

n/a Beiträge
 
#12

Re: Wie zuverlässig ist der MemoryLeak-Report von FastMM?

  Alt 12. Mär 2008, 08:35
Zitat von Nuclear-Ping:
"GDI" ist relativ unbekanntes Theretorium für mich. Hab den Begriff zwar schon zig mal gehört, aber direkt zu tun hatte ich damit noch nicht. Wie können da Leaks entstehen?
Dazu kurz eine Frage: hälst du Grafiken in den Listen? Beziehungsweise kümmerst du dich selbst um die Darstellung (UserDraw uns so Zeugs)?
  Mit Zitat antworten Zitat
Nuclear-Ping
(Gast)

n/a Beiträge
 
#13

Re: Wie zuverlässig ist der MemoryLeak-Report von FastMM?

  Alt 12. Mär 2008, 08:39
Ja, während der Sendung läuft zB meist ein Oszilloskop (kommt drauf an, was man für 'ne Hardware dranhängen hat) und die dazu gehörigen Listen werden dargestellt. Die können pro Eintrag zwei Symbole haben, was unterm Strich immer ein Bild ist. Selbst wenn kein Symbol eingetragen wurde, wird halt ein "Kein Symbol"-Bild gezeigt, was aus einer ImageList kommt. Sonst wird das dazugehörige Bild von einer externen Quelle geladen.

[edit]
Hier mal der Code vom Zeichnen der Symbole.
Delphi-Quellcode:
procedure DrawCellSymbol (Sender: TBaseVirtualTree; TargetCanvas: TCanvas;
  Node: PVirtualNode; Column: TColumnIndex; CellRect: TRect;
  ImageList: TImageList; Symbol1Col, Symbol2Col: Integer;
  CategoryId: Integer);
var
  bmp: TBitmap;
  ThumbFileName,
  Text: String;
  SymbolIndex,
  DrawX, DrawY,
  ImageIndex: Integer;
  Data: PDatabaseData;
  DrawRect: TRect;
  JPG: TJPEGImage;
  iSymbolType: TSymbolType;
  iSymbol: TSymbolStream;
  HasThumbnail,
  SaveThumbnail,
  DrawSymbol: Boolean;
begin
  if (Column <> Symbol1Col) and
     (Column <> Symbol2Col) then
    Exit;

  Data := Sender.GetNodeData (Node);

  SymbolIndex := 0;
  if Column = Symbol1Col then
    begin
      SymbolIndex := 1;
      DrawSymbol := TRUE;
      iSymbolType := Data.SymbolType1;
      iSymbol := Data.Symbol1;
    end
  else if Column = Symbol2Col then
         begin
           SymbolIndex := 2;
           DrawSymbol := TRUE;
           iSymbolType := Data.SymbolType2;
           iSymbol := Data.Symbol2;
         end
       else DrawSymbol := FALSE;

  ThumbFileName := GetApplicationPersonalThumbsPath +
                   inttostr (Node.Index) +
                   inttostr (Data.ID) +
                   inttostr (Data.HealingsheetIndexID) +
                   inttostr (SymbolIndex) +
                   inttohex (CategoryId, 8) +
                   '.bmp';

  if DrawSymbol then
    begin
      bmp := TBitmap.Create;
      try
        case iSymbolType of
          stNoSymbol:
            ImageIndex := 0;
          stImage:
            ImageIndex := 1;
          stSound:
            ImageIndex := 2;
          stVibration:
            ImageIndex := 4;
          else
            ImageIndex := 3;
        end;

        // Wenn Symbol ein Bild ist, externe Datei laden
        if (iSymbolType = stImage) then
          begin
            HasThumbnail := FileExists (ThumbFileName);
            if HasThumbnail then
              bmp.LoadFromFile (ThumbFileName);

            iSymbol.Position := 0;
            if not HasThumbnail then
              begin
                if (Is_BLOB_JPG (iSymbol)) then
                  begin
                    JPG := TJPEGImage.Create;
                    JPG.LoadFromStream (iSymbol);
                    bmp.Assign (JPG);
                    FreeAndNil (JPG);
                  end
                else bmp.LoadFromStream (iSymbol);
              end;
          end
        else ImageList.GetBitmap (ImageIndex, bmp); // ... sonst aus ImageList das dazugehörige Symbol
             
        with TargetCanvas do
          begin
            Font.Color := Sender.Font.Color;
            Text := SymbolTitles[ImageIndex];

            DrawRect := ClipRect;
            DrawRect.Right := DrawRect.Right - 8;

            DrawText (TargetCanvas.Handle,
                      PChar (Text),
                      Length (Text),
                      DrawRect,
                      DT_SINGLELINE or DT_VCENTER or DT_RIGHT);

            if (iSymbolType = stImage) then
              begin
                SaveThumbnail := FALSE;
                // Bild neu skalieren?
                SaveThumbnail := ResizeBitmap (bmp, 80, 80);

                DrawX := ClipRect.Left +
                         Round ((ClipRect.Right - ClipRect.Left) / 2) -
                         Round (bmp.Width / 2);

                DrawY := ClipRect.Top +
                         Round ((ClipRect.Bottom - ClipRect.Top) / 2) -
                         Round (bmp.Height / 2);

                Draw (DrawX, DrawY, bmp);

                if SaveThumbnail then
                  if (Data.ID = 0) and
                     (Data.HealingsheetIndexID = 0) then
                    SaveThumbnail := FALSE;

                if SaveThumbnail then
                  bmp.SaveToFile (ThumbFileName);
              end
            else begin
                   DrawRect := ClipRect;
                   DrawRect.Left := DrawRect.Left +
                                    (Sender as TVirtualStringTree).Margin +
                                    4;
                   DrawRect.Top := DrawRect.Top + (Round ((DrawRect.Bottom - DrawRect.Top) / 2) - 16);

                   Draw (DrawRect.Left,
                         DrawRect.Top,
                         bmp);
                 end;
          end;

      finally
        FreeAndNil (bmp);
      end;
    end;
end;
[/edit]
  Mit Zitat antworten Zitat
Dax
(Gast)

n/a Beiträge
 
#14

Re: Wie zuverlässig ist der MemoryLeak-Report von FastMM?

  Alt 12. Mär 2008, 08:47
Ja, das könnte dann passen... GDI ist die Graphikschnittstelle von Windows (mittlerweile durch GDI+ mehr oder weniger abgelöst?) - aber wenn du sagst, dass FastMM keine Speicherlecks anzeigt, wundere ich mich, warum GDI-Handles nicht freigegeben werden
  Mit Zitat antworten Zitat
Nuclear-Ping
(Gast)

n/a Beiträge
 
#15

Re: Wie zuverlässig ist der MemoryLeak-Report von FastMM?

  Alt 12. Mär 2008, 09:07
Ist das normal, dass AQtime den Prozess so derb bremst, dass er jetzt zum Laden der Liste mit 560 Einträgen (440MB) nach über ner halben Stunde grad mal bei der Hälfte ist (221MB laut TM), wo er vorher paar Sekunden gebraucht hat ...?

... Und zwei AVs "Lesen von Adresse 00000000" kamen beim Start des Projekts aus AQtime auch.

[edit]
Sorry Bernhard, aber was ist das bitte für eine "Award winning"-Software die du mir da empfohlen hast?

Ich hocke hier schon seit über 'ner Stunde ohne Ergebnisse rum und versuche, das mein Projekt mal eine Liste sendet, damit ich mal was in AQtime sehe. Ich hab mein Projekt gestartet und AQtime an den Prozess angehangen.

Aber selbst bei nur einer Liste im Sendeplan mit nur einem Text-Eintrag hat der hier seit über 5 Minuten voll zu tun, Prozess ist blockiert, er müllt mir den Speicher weiter zu (77MB ... es ist nur ein Text-Eintrag) und kommt nicht zu potte ...
[/edit]
  Mit Zitat antworten Zitat
Nuclear-Ping
(Gast)

n/a Beiträge
 
#16

Re: Wie zuverlässig ist der MemoryLeak-Report von FastMM?

  Alt 12. Mär 2008, 10:43
Sorry für's frühe pushen ... Aber ich komme hier echt nicht weiter und stehe (mit Druck von aussen) voll auf dem Schlauch.

Hab das AQtime grad mal für über 15min laufen lassen (war duschen ^^) mit dem Versuch, dass er doch bitte diese eine kleine Mini-Liste abarbeitet, damit ich mal irgendwas sehe. Und als ich wieder kam, hatte er 120MB Speicher-Last, 100% CPU Last und war immernoch am laden. Also das kanns doch nicht sein. Ohne AQ im Hintergrund lädt er die Liste innerhalb von 3sek.

Angenommen selbst wenn das AQtime funktionieren würde, was würde ich denn da für Informationen erhalten? Wie würde ich an diese GDI-Leaks rankommen?
  Mit Zitat antworten Zitat
Benutzerbild von Bernhard Geyer
Bernhard Geyer

Registriert seit: 13. Aug 2002
17.171 Beiträge
 
Delphi 10.4 Sydney
 
#17

Re: Wie zuverlässig ist der MemoryLeak-Report von FastMM?

  Alt 12. Mär 2008, 10:53
Zitat von Nuclear-Ping:
Ist das normal, dass AQtime den Prozess so derb bremst, dass er jetzt zum Laden der Liste mit 560 Einträgen (440MB) nach über ner halben Stunde grad mal bei der Hälfte ist (221MB laut TM), wo er vorher paar Sekunden gebraucht hat ...?
Hast du wohl Line-Profiling für deine komplette Source aktiviert?

Zitat von Nuclear-Ping:
... Und zwei AVs "Lesen von Adresse 00000000" kamen beim Start des Projekts aus AQtime auch.
Hatte mal Probleme mit einem älteren Build. Aber aktuell keine Probleme mehr.

Zitat von Nuclear-Ping:
Ich hocke hier schon seit über 'ner Stunde ohne Ergebnisse rum und versuche, das mein Projekt mal eine Liste sendet, damit ich mal was in AQtime sehe. Ich hab mein Projekt gestartet und AQtime an den Prozess angehangen.
Wieso startest du dein Programm nicht über AQTime?
Windows Vista - Eine neue Erfahrung in Fehlern.
  Mit Zitat antworten Zitat
Nuclear-Ping
(Gast)

n/a Beiträge
 
#18

Re: Wie zuverlässig ist der MemoryLeak-Report von FastMM?

  Alt 12. Mär 2008, 11:40
Zitat von Bernhard Geyer:
Hast du wohl Line-Profiling für deine komplette Source aktiviert?
Aktiviert hab ich nichts. Alles auf Standard gelassen. Hab aber grad gesehen, dass in der Tat "By lines" aktiviert war. Hab es umgestellt auf "By routines", dauert aber genauso lange alles. Also hab grad eben nach ~4min den Versuch abgebrochen, dass er die Liste lädt. Wenn ich auf "none" stelle, macht er zwar los, aber kA ob er dann irgendwas nachvollziehbares liefert.

Zitat von Bernhard Geyer:
Zitat von Nuclear-Ping:
... Und zwei AVs "Lesen von Adresse 00000000" kamen beim Start des Projekts aus AQtime auch.
Hatte mal Probleme mit einem älteren Build. Aber aktuell keine Probleme mehr.
Hm, grad wieder probiert. Nun kamen auch keine AVs mehr.

Zitat von Bernhard Geyer:
Zitat von Nuclear-Ping:
Ich hocke hier schon seit über 'ner Stunde ohne Ergebnisse rum und versuche, das mein Projekt mal eine Liste sendet, damit ich mal was in AQtime sehe. Ich hab mein Projekt gestartet und AQtime an den Prozess angehangen.
Wieso startest du dein Programm nicht über AQTime?
Eben wegen den AVs.

----

So, nun hab ich einen Report hier. Die Frage nur, was mach ich damit? Weil so richtig schlau werde ich nicht draus:
Zitat:
AQtime Resource Profiler
Session information

Started: 12.03.2008 12:30:05
Ended: 12.03.2008 12:34:37
Execution time: 00:04:32:532

566 errors occurred during profiling.
1958 leaks found in resources.


Leak Table:

Sys strings 1952
FindFirst 3
Handle 3

Run settings
Profiling mode: Normal
Host Application:
Parameters:
Work Directory:

Profiler options
Collect stack information: None

System information
Operating system: Microsoft Windows XP Service Pack 2 (version: 5.1 Build 2600)
Total physical memory: 1572336 Kb
Available physical memory: 592136 Kb
Total virtual memory: 2097024 Kb
Available virtual memory: 1860032 Kb
Processor type: AMD Athlon(tm) XP 2500+, Frequency: ~1830 MHz.
Number of processors: 1
Die "566 errors occurred during profiling" sind alles verweise auf System-DLLs ...

- gdi32.dll: CreateDIBSelection "An error occured during the function execution"
- gdi32.dll: CreateDIBSelection "Ungültiges Fensterhandle"
- ...
- kernel32.dll: CreateEventA "Zugriff verweigert"
- etc.

Die Leaks hab ich mal als Txt Report angehangen (HTML geht nicht als Attachment). Nur was mach ich damit? Wie komme ich an die SysString Leaks?

Alles noch bisschen Bahnhof für mich, sorry.

[edit]
Attachment aktualisiert
[/edit]
Angehängte Dateien
Dateityp: txt objects_120308-1234_125.txt (170,4 KB, 5x aufgerufen)
Dateityp: txt classes_120308-1234_150.txt (2,1 KB, 5x aufgerufen)
  Mit Zitat antworten Zitat
Nuclear-Ping
(Gast)

n/a Beiträge
 
#19

Re: Wie zuverlässig ist der MemoryLeak-Report von FastMM?

  Alt 13. Mär 2008, 13:49
*push*

... Stehe immernoch auf dem Schlauch. Was hat es mit diesen "Sys strings" auf sich? Wie komme ich daran und wie kann ich sie freigeben? Googlen nach "Sys strings" oder "AQtime Sys strings leak" brachte nicht die erhofften Hinweise.

Ich hab jetzt quasi seit gestern hier am Code gehockt und mal ALLE dynamischen Arrays (einige wurden auch während der Sendung verwendet) als TList-Nachfahren gemacht und den ganzen Spaß durch den ganzen Code hinweg konsequent ersetzt.

Ergebnis: AQtime heult mir immernoch was von 1500 "Sys strings" Leaks vor, der TaskManager wächst langsam aber stetig mit jeder fertigen Sendung, FastMM sagt nix von Speicherlecks und mein Sandsack kriegt schon Löcher ...

Help ...

[edit]
Vorallem das komische, was mir Mr. Chef auch schon berichtete und was ich vorhin hier auch hatte: Stopt man die Sendungen, geht er von Anfangs 12MB nur noch auf vlt. 32MB - durch die ganzen Listen die durchgelaufen sind.
Wechselt man nun paar mal den Task, macht irgendwas anderes, so hab ich durch Zufall vorhin gesehen, dass meine .exe im TaskManager plötzlich nur noch 6MB Speichernutzung angezeigt hat, was dann aber wieder auf 12 hoch ging ...
[/edit]
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 2 von 2     12   


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 23:49 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz