Handle Count erhöht sich

[venice2]

Der Handle Counter erhöht sich meine Frage wäre warum?

Ich starte die Anwendung.
Jedesmal wenn ich ein neues Plugin starte erhöht sich der Handle Count um 1.
Ich kann im Process Explorer aber verfolgen das die DLL's entladen werden und zwar daran weil sie aus der Liste des Prozesses dann entfernt werden.
Welche Auswirkung hat das auf die gesamte Anwendung bei Dauerlauf?

Wie kann sich also der Count erhöhen wenn doch die DLL's korrekt entladen werden.

Es geht mir um das Handle der DLL nicht um ein Window Handle.

[hoika]

Hallo,
viell. weil es für Windows einfacher ist,
neue Nummern zu erzeugen statt alte wieder zu verwenden?

[venice2]

Zitat:

Zitat von hoika (Beitrag 1470516)

Hallo,
viell. weil es für Windows einfacher ist,
neue Nummern zu erzeugen statt alte wieder zu verwenden?

Verstehe ich nicht so recht was du mir sagen willst.
Welche Auswirkungen hat das auf meine Anwendung wenn diese als Beispiel 2 Wochen im Dauerbetrieb läuft 24 Stunden am Tag?

Was muss ich tun bzw wie kann ich das Analysieren welche Handles das sind.
Denn wie ich schon sagte werden die Plugins freigegeben.
Nur der Counter erhöht sich kontinuierlich.

Die Handles freigegeben warum erhöht sich trotzdem der Counter des prozess.

[hoika]

Hallo,
Ok, dann habe ich das falsch verstanden.
Was sagt denn FastMM4?

Was sind das für Plugins?
Ein bisschen Code wäre schön.
Und ein Minimal-Bsp.

Um zur Ausgangsfrage zukommen.
Irgendwann schmiert dein Windows ab wegen Ressourcenmangel.

[venice2]

Zitat:

Zitat von hoika (Beitrag 1470518)

Hallo,
Ok, dann habe ich das falsch verstanden.
Was sagt denn FastMM4?

Ist das nun ein Handle Leak oder nicht.
FastMM4 oder Eurekalog sagen dazu nichts.
Beide abwechslungsweise aktiviert.

Zitat:

Was sind das für Plugins?

Visualisierungs Plugins Sonique.

Werden aber freigegeben wäre das nicht so würde die Anwendung hängen.
Quelltext kann ich leder nicht veröffentlichen.
Aber es würde mir reichen wenn ich wüsste wie ich das am besten Analysieren kann.

[hoika]

Hallo,
alles ausklammern (Minimalbeispiel).
Laufen lassen. Testen.
Schrittweise den Code reinnehmen, laufen lassen. Testen.

Eskönnten GDI--Handles sein.

[TiGü]

Ich verweise auf:
https://www.delphipraxis.net/1453741-post3.html

[Delphi.Narium]

Sicher, dass das Handles sind, die Du selbst "im Zugriff" hast und nicht eventuell welche, die die PlugIns nicht "sauber wegräumen"?

Wenn Du also ein PlugIn lädst, könnte es ja durchaus sein, dass dieses, für was auch immer, ein Handle benötigt und dieses beim Beenden seiner selbst nicht wieder freigibt?

Dazu müssten Dir dann FastMM4 oder Eurekalog auch nichts sagen, da sie darauf (vermutlich) keinerlei Einfluss haben, dies ggfls. sogar nie erfahren und es Dir daher auch nicht mitteilen können.

[Michael II]

... und in Eurekalog hast du unter "Memory problems > Memory leaks" sowie "Resource leaks" die Einstellungen so gewählt, dass wirklich "alles" geloggt wird?

[venice2]

Zitat:

Zitat von TiGü (Beitrag 1470540)

Ich verweise auf:
https://www.delphipraxis.net/1453741-post3.html

Danke.

Zitat:

Sicher, dass das Handles sind, die Du selbst "im Zugriff" hast und nicht eventuell welche, die die PlugIns nicht "sauber wegräumen"?

Nein. Wie denn auch?

Zitat:

... und in Eurekalog hast du unter "Memory problems > Memory leaks" sowie "Resource leaks" die Einstellungen so gewählt, dass wirklich "alles" geloggt wird?

Ja.

[himitsu]

Zitat:

Zitat von hoika (Beitrag 1470516)

weil es für Windows einfacher ist,
neue Nummern zu erzeugen statt alte wieder zu verwenden?

Es ist auch fehlerunganfälliger, wenn kurz nacheinander nicht die selbe ID vergeben wird.

Aber das betrifft nur den "Wert" des Handles, aber nicht die "Anzahl" aller Handles.

Wenn die Anzahl steigt, dann würde ich erstmal an ein "Speicherleck" denken, also dass Handles nicht wieder geschlossen/freigegeben werden


FastMM kennt nur Speicher, der über ihn Reserviert wurde ... Fremder Speicher (auch an ihm vorbei, direkt an VirtualAlloc) oder andere Handles interessieren ihn natürlich garnicht. (er weiß ja nichts davon)




Entweder die Tools von SysInternals.
Oder man macht sich einen Snapshot (alle Handles suchen und merken) und vergleicht das nachher,
dann muß man "nur" noch die neuen Handles auflösen und versuchen rauszubekommen was für ein Handle das ist.

[venice2]

Zitat:

Wenn die Anzahl steigt, dann würde ich erstmal an ein "Speicherleck" denken, also dass Handles nicht wieder geschlossen/freigegeben werden

Library wird freigegeben mit FreeLibrary Rückgabe ist immer true.
Mit GDIView kann ich keine probleme bzgl. GDI>Handles feststellen.

FastMM4 gibt keinen Fehler aus.
Schwierig.

[TiGü]

Und der andere Handle-Viewer von NirSoft?

[venice2]

Zitat:

Zitat von TiGü (Beitrag 1470587)

Und der andere Handle-Viewer von NirSoft?

Zeigt auch keine Auffälligkeiten.
Die GDI>Handles bleiben stabil aber der Counter inkrementiert trotzdem.

Habe einen Thread den ich nicht extra deaktiviere wenn ich ein Plugin ändere weil er das Timing regelt.
Dachte das es vielleicht daran liegt habe ihn deaktiviert und beim ändern eines neuen Plugins wieder aktiviert ändert aber auch nichts am Inkrementieren des Counter.

[himitsu]

Es gibt verschiedene "Handles", drum hat der Taskmanager auch mehrere Spalten dafür, z.B.
* Handles (z.B. Dateien und Dergleichen)
* GDI-Objects (die aus'm GDI)

[venice2]

Zitat:

Zitat von himitsu (Beitrag 1470596)

Es gibt verschiedene "Handles", drum hat der Taskmanager auch mehrere Spalten dafür, z.B.
* Handles (z.B. Dateien und Dergleichen)
* GDI-Objects (die aus'm GDI)

Dessen bin ich mir bewusst und das ist der grund warum es so schwer ist das Problem zu lokalisieren.
Welche Schritte ich verfolge habe ich ja schon geschrieben.

Nochmal.
DLL entladen. true
GDI_Handles keine Auffälligkeiten.
Dateien werden freigegeben siehe DLL entladen.
Threads ein und ausschalten versucht. Keine Änderung beim Counter.
Das Handle das über BeginThread erstellt wird, wird ebenfalls geschlossen.

Delphi-Quellcode:

CloseHandle(Handle);

Danke.

[Delphi.Narium]

Wieviele Handles hat Dein Programm vor dem Laden der DLL?

Wieviele Handles benötigst Du beim Laden der DLL? (vermutlich 1)

Wieviele Handles hat das Programm, wenn die DLL geladen ist? (vermutlich 1, wenn mehr, benötigt die DLL selber auch noch welche)

Wieviele Handles hat Dein Programm nach der Freigabe der DLL?

Theoretisch Handles des Programmes + 1 beim Laden der DLL - 1 durch die Freigabe der DLL.

Sollte also zu einem Nullsummenspiel werden: Handles vorher = Handles nachher.

Wenn aber bei geladener DLL mehr als 1 Handle hinzukommt, aber beim Freigeben der DLL nur 1 Handle entfernt wird, liegt der Fehler (höchstwahrscheinlich) in der DLL.

Hab' keine Ahnung, wie man das sicher und verlässlich überprüfen kann.

Im Zweifelsfalle im Debugger an alle möglichen Stellen 'nen Breakpoint setzen und dort dann jeweils nachschauen, wie es so bei den Handles aussieht.

DLL entladen. true: Das heißt aber nicht, dass die DLL selbst "vernünftig" aufgeräumt hat, sondern nur, dass Dein Programm die DLL "vernünftig" entladen hat. Das schließt halt nicht aus, dass hier trotzdem noch Handles übrigbleiben.

[himitsu]

https://docs.microsoft.com/en-us/sys...wnloads/handle
oder den Process Explorer

Ich hatte auch mal vor Jahren ein Handle-Leck
und hab mir am Ende ganz böse einen extrem ineffektiven Code gebastelt, der alle eine Milliarde möglichen Handles durchprobiert, die "Gültigen" gezählt und dann vor/nach verdächtigen Funktionsaufrufen die Differenz gebildet.

HANDLE = LongWord (Integer), aber die Handles sind "immer" an Integergrenzen ausgerichtet (weil ist "aktuell" zufällig direkt der Index zur HandleListe des Systems), deswegen ging es am Ende 3/4 schneller. :roll:


Das Ergebnis könnte man sich auch in einer Liste oder Bitmaske speichern und für den Vergleich nutzen.
Und teilweise ist es dann auch möglich zum Handle auch einen Namen zu bekommen.
z.B. GetFinalPathNameByHandle, GetModuleFileName usw.

[venice2]

Zitat:

Theoretisch Handles des Programmes + 1 beim Laden der DLL - 1 durch die Freigabe der DLL.

Der Handle Count ändern sich nicht nach der Freigabe.
Und wird dann beim nächsten start einer anderen DLL inkrementiert.

Zitat:

oder den Process Explorer

Den verwende ich.

Warum bekomme ich mit LoadLibrary(xxx.dll) immer das gleiche Handle?

[Michael II]

Zitat:

Zitat von venice2 (Beitrag 1470602)

Warum bekomme ich mit LoadLibrary(xxx.dll) immer das gleiche Handle?

Bei früheren Windows Versionen landeten DLLs nach dem Entladen noch einige Zeit im Cache. Ich weiss nicht, ob dem bei bei aktuellen Wins noch so ist. Es könnte ja sein... und dann wäre das gleiche Handle irgendwie "logisch".

(Bei früheren Win Versionen konntest du via [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Explorer] AlwaysUnloadDLL=1 erzwingen, dass die DLL nach dem Entladen nicht noch im Cache landete.)

Es gibt sicher Leute hier, welche ganz genau wissen, wie das heute so läuft...

[venice2]

Zitat:

Es könnte ja sein... und dann wäre das gleiche Handle irgendwie "logisch".

Ja solange es sich immer um die gleiche DLL handelt ist das ja auch kein problem.

Aber ich lade unterschiedliche DLLs also sollte eigentlich das Handle auch unterschiedlich sein.
Abhängig von der jeweiligen DLL egal ob sich diese im Cache befindet oder nicht.

Also wenn die Handles immer gleich sind welche DLL wird denn dann nun entladen?

[himitsu]

Das "Handle" einer DLL entspricht aktuell "zufällig" der Adresse im RAM (bei Win32 ... 64 weiß ich nicht)
und so lange die DLL immer an der selben Stelle geladen wird, bleibt sie auch dort.

Außerdem, wenn die DLL beim FreeLibrary nicht freigegeben wird, weil z.B. noch ein anderes Handle drauf zeigt (Referenzzählung), dann lädt das nächste LoadLibrary auch nicht neu und bekommt das aktive Handle.

Statt LoadLibrary vorher einfach mal mit GetModulHandle nachsehn, ob die schon/noch da ist.

Jede EXE/DLL hat zwar eine LadeAdresse und würde "eigentlich" auch immer an der Stelle geladen, also hätte somit immer die selbe Adresse/Handle bekommen, ABER
* fast Alle Entwickler vergessen die zu setzen, somit steht die Vorgabe immer auf $00400000, was oft belegt ist (wenn mehrere EXE/DLL die Gleiche haben) und somit verschoben wird
** allerdings hat Windows einen Cache und merkt es sich ... um nicht jedesmal neu die Reallocations neu zu berechnen
** dieser Cache sorgt auch dafür, dass mehrere Instanzen der DLL in verschiedenen Programmen bzw. Programminstanzen (Programm mehrmals gestartet) auch "möglichst" die selbe Adresse haben (gemeinsam genutzter Speicher)
http://docwiki.embarcadero.com/RADSt...e-Basisadresse
* und man kann im Windows auch eine Sicherheitfunktion aktivieren, womit EXE und DLLs immer neu zufällig positioniert werden, damit Hacker/Viren/Trojaner mit statischen Zeigern kein "leichtes" Spiel haben, z.B. durch einen billigen Bufferoverflow im Browser

Zitat:

aber ich lade unterschiedliche DLLs also sollte eigentlich das Handle auch unterschiedlich sein.

so lange die Entwickler keinen Mist gebaut haben ... z.B. überall die gleiche ImageBase

[venice2]

Zitat:

Statt MSDN-Library durchsuchenLoadLibrary vorher einfach mal mit MSDN-Library durchsuchenGetModulHandle nachsehn, ob die schon/noch da ist.

Könnte ich machen wobei ein FreeLibrary letztendlich auch nichts anderes macht.
Entweder die Rückgabe ist true dann existiert die DLL noch oder aber false dann nicht. Oder?

Glaube aber trotzt deiner guten Beschreibung wird es nicht mein Problem lösen.

Zitat:

Außerdem, wenn die DLL beim FreeLibrary nicht freigegeben wird, weil z.B. noch ein anderes Handle drauf zeigt (Referenzzählung)

Wie ich schon sagte ist immer True also kann kein Handle noch auf DLL zeigen.

Ist wohl wieder ein Spezialfall. JA meistens sitzt das Problem davor ist bekannt. ;) Falls so ein Spruch wieder kommt.

[himitsu]

Nein, das mit dem Result ist ganz einfach (wenn ich die Hilfe richtig gelesen hab :stupid:)

entweder es ist ein gültiges Handle, dann ist es True,
oder es ist ungültig, oder 0 oder -1 (INVALID_HANDLE_VALUE) und dann ist die Funktion nicht erfolgreich, also False.
Gehört das Handle zu einem anderen Prozess und es fehlen somit die Rechte, dann schlägt es auch mit einem gültigen existierendem Handle fehl.

Ob die DLL wirklich entladen wurde, wird damit nicht gesagt.


Stell es dir wie ein Interface vor (_AddRef/_Release):
True = der Referenzzähler wurde erfolgreich dekrementiert (ob er dabei 0 und die DLL entladen wurde, erfährst du nicht)
False = beim Interface würde (hoffentlich) eine Zugriffsverletzung kommen

[venice2]

Ach so ist das.

Dachte immer es sagt aus ob die DLL entladen wurde oder nicht.
Desto trotz kann ich im Process Explorer erkennen das die DLL vom Prozess gelöst - entladen wurde.

Welchen sinn macht FreeLibrary wenn man damit nicht garantieren kann das die DLL auch entladen wurde.

Ob die DLL entladen wurde prüfe ich jetzt so (ändert aber auch nichts am counter)

Delphi-Quellcode:

  if DllHandle <> 0 then
  begin
    FreeLibrary(DllHandle);
    module := GetModuleHandle(DLLPath);
    if module = 0 then
      DllHandle := 0;
  end;

So kann ich wenigstens prüfen ob diese vom Prozess gelöst wurde.
Der code ist nur ein Beispiel nicht vollständig!

[venice2]

Ich glaube habe den Fehler gefunden.
Ich erstelle ein Event

Delphi-Quellcode:

    hEventFree := CreateEvent(nil, False, False, nil);
    PostThreadMessage(ThreadId, WM_QUIT, 0, 0);
    try
      repeat
        WaitRe := WaitForSingleObject(hEventFree, 15);
        if WaitRe <> WAIT_OBJECT_0 then
          WinProcessMessages;
      until WaitRe = WAIT_OBJECT_0;
    finally
      CloseHandle(hEventFree); // hat gefehlt
      ThreadId := 0;
    end;

wenn der Thread beendet wird setze ich das Event

Delphi-Quellcode:

SetEvent(hEventFree);

Habe das Event Handle aber nicht freigegeben.

Delphi-Quellcode:

CloseHandle(hEventFree);

jetzt bleibt der Counter constant.
Hoffe das war mein Problem. Oder doch nicht?
Würde mich mal interessieren ob ich richtig liege.

Das man das Event Handle freigeben muss war mir nicht bekannt.
Auch hier im Forum habe ich noch nicht gelesen das es jemand tut.

Frage mich nur warum hat FastMM4 und oder EurekaLog das nicht erkannt.

[Dalai]

Zitat:

Zitat von venice2 (Beitrag 1470634)

Das man das Event Handle freigeben muss war mir nicht bekannt.

Steht (ganz unten) in den Remarks zur API-Funktion CreateEvent:

Zitat:

Use the CloseHandle function to close the handle. The system closes the handle automatically when the process terminates. The event object is destroyed when its last handle has been closed.

Zitat:

Frage mich nur warum hat FastMM4 und oder EurekaLog das nicht erkannt.

Simpel: Weil sowas nicht von einem Delphi Memory Manager (MM) erfasst wird bzw. werden kann. Gleiches gilt für Icons, die man mit LoadIcon oder LoadImage lädt. Die gehen am Delphi MM vorbei, und daher bekommt der davon nix mit.

Grüße
Dalai

[shebang]

Hat die Benutzung von

Delphi-Quellcode:

CreateEvent

irgendwelche Vorteile gegenüber

Delphi-Quellcode:

TEvent.Create

?

[himitsu]

Nein.

TEvent kapselt im Windows auch nur diese API,
mit dem Vorteil, dass es auf anderen Plattformen auch was Vergleichbares nutzt, wo die WinAPI nicht bekannt ist.

Selbes gilt auch für CriticalSections und Dergeleichen, wo es ebenfalls inzwischen im Delphi eine Kapselung gibt (TCriticalSection)
Aber da darf man auch gern TMonitor nehmen (Achtung, das Richtige, weil jemand war auf die geile Idee gekommen diesen Namen zu nehmen, obwohl es in Screens.pas sowas schon seit Jahrzehnten gab)

[venice2]

Zitat:

Zitat von Dalai (Beitrag 1470646)

Zitat:

Zitat von venice2 (Beitrag 1470634)

Das man das Event Handle freigeben muss war mir nicht bekannt.

Steht (ganz unten) in den Remarks zur API-Funktion CreateEvent:

Zitat:

Use the CloseHandle function to close the handle. The system closes the handle automatically when the process terminates. The event object is destroyed when its last handle has been closed.

Zitat:

Frage mich nur warum hat FastMM4 und oder EurekaLog das nicht erkannt.

Simpel: Weil sowas nicht von einem Delphi Memory Manager (MM) erfasst wird bzw. werden kann. Gleiches gilt für Icons, die man mit LoadIcon oder LoadImage lädt. Die gehen am Delphi MM vorbei, und daher bekommt der davon nix mit.

Grüße
Dalai

Ok. Danke.