JVHIDControllerClass mit Speicherlecks?

[Mattze]

Hi,

ich versuche mich gerade an HID mit der HID-Komponente von R. Marquardt.
Beim Test der Usagedemo mit FastMM4 bekomme ich eine Reihe von Speicherlecks.
Es scheint mindestens bei

Delphi-Quellcode:

  HidCtl.CheckOutByIndex(Dev, Idx);

zu sein.

Wer weiß, was da los ist bzw. wie man das umgeht?
(Delphi 7 Prof.)

Gruß
Mattze

[Dezipaitor]

Vllt postest du die FastMM logs hier, damit man es sich anschauen kann.

[Mattze]

Hallo,

mach' ich doch glatt...

Gruß
Mattze

[Dezipaitor]

Du musst externe Debuggerinfo einschalten und neu erstellen.
Dann siehst du die Funktionsnamen, wo der Speicher alloziert wurde.

[Mattze]

Hallo,

guter Rat. Wäre ich nie darauf gekommen...
Meines Wissens SIND die eingeschaltet, jedenfalls funktioniert es mit der Anzeige bei anderen Programmen.

Vielleicht weiß ich ja nicht, wo ich noch etwas ein- bzw. ausschalten muss.
Gib mir mal einen Tipp!

Ansonsten: Besser wird das LOG-File wahrscheinlich nicht!
Wo suchen???

Gruß
Mattze

[Bernhard Geyer]

Zitat:

Zitat von Mattze

Meines Wissens SIND die eingeschaltet, jedenfalls funktioniert es mit der Anzeige bei anderen Programmen.

Für detailreichere Debuginfos werden TD32-Debuginfos benötig.

[Mattze]

Hallo,

Recht hast Du!!!
Die Map-Datei war beim UsageDemo-Projekt (natürlich) ausgeschaltet.
Wer kommt aber auch auf sowas... ;-)

Hier das komplette Log.
(Natürlich suche ich jetzt auch. Nun weiß ich ja, wo ich gucken muss...
Aber trotzdem...)

Gruß
Mattze

[Mattze]

Hallo,

man soll zwar niemals nie sagen, aber ich finde das wohl NIE raus.
Ich habe mal nach fehlenden Freigaben von PnPInfo gesucht und überall mal probiert, aber da war das Problem nicht dabei - oder er ist vorher per Zugriffsverletzung abgeschmiert.

Also bitte ich doch um Hilfe!

Gruß
Mattze

[jbg]

Also mit kommt der Code in "TJvHidDeviceController.Destroy" etwas seltsam vor.

Delphi-Quellcode:

      if IsCheckedOut then
        DoUnplug // pull the plug for checked out TJvHidDevices
      else
        Free; // kill TJvHidDevices which are not checked out

Das DoUnplug führt kein Free aus und FList ist eine TList, kümmert sich also nicht um die Objekte. Das ist dann wohl per Definition ein Speicherleck.

[Mattze]

Hallo,

vielen Dank!
Das FList (: TLIST) kam mir auch etwas merkwürdig vor.
Mir schien auch zu fehlen, dass die "internen Strukturen" davon ordentlich freigegeben werden, bevor es selber zerstört wird. Ich hatte nur noch nicht das §eventuelle Wo" gefunden.
Ich dachte aber auch, dass das nicht sein könne...

Mir geht vor allem diese FPnPInfo nicht aus dem Sinn. Das ist etwas, das in jedem Listeneintrag der FList existiert und freigegeben werden müsste. Das andere habe ich noch nicht richtig überprüft. Kann aber durchaus sein, dass es wirklich und nur an der Freigabe der Liste liegt.
Ich habe mich nur nicht getraut, daran was zu machen...

Aber nun probiere ich das auch mal.

Danke noch mal!

Gruß
Mattze