AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Handle Count erhöht sich

Ein Thema von venice2 · begonnen am 28. Jul 2020 · letzter Beitrag vom 29. Jul 2020
Antwort Antwort
Seite 3 von 3     123
venice2
(Gast)

n/a Beiträge
 
#21

AW: Handle Count erhöht sich

  Alt 28. Jul 2020, 17:58
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?
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.017 Beiträge
 
Delphi 12 Athens
 
#22

AW: Handle Count erhöht sich

  Alt 28. Jul 2020, 18:34
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 MSDN-Library durchsuchenLoadLibrary vorher einfach mal mit MSDN-Library durchsuchenGetModulHandle 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
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests

Geändert von himitsu (28. Jul 2020 um 18:38 Uhr)
  Mit Zitat antworten Zitat
venice2
(Gast)

n/a Beiträge
 
#23

AW: Handle Count erhöht sich

  Alt 28. Jul 2020, 21:24
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.

Geändert von venice2 (28. Jul 2020 um 21:52 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.017 Beiträge
 
Delphi 12 Athens
 
#24

AW: Handle Count erhöht sich

  Alt 28. Jul 2020, 22:36
Nein, das mit dem Result ist ganz einfach (wenn ich die Hilfe richtig gelesen hab )

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
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests

Geändert von himitsu (28. Jul 2020 um 22:38 Uhr)
  Mit Zitat antworten Zitat
venice2
(Gast)

n/a Beiträge
 
#25

AW: Handle Count erhöht sich

  Alt 28. Jul 2020, 22:40
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!

Geändert von venice2 (28. Jul 2020 um 23:13 Uhr)
  Mit Zitat antworten Zitat
venice2
(Gast)

n/a Beiträge
 
#26

AW: Handle Count erhöht sich

  Alt 29. Jul 2020, 01:03
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
SetEvent(hEventFree);

Habe das Event Handle aber nicht freigegeben.
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.

Geändert von venice2 (29. Jul 2020 um 02:57 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Dalai
Dalai

Registriert seit: 9. Apr 2006
1.679 Beiträge
 
Delphi 5 Professional
 
#27

AW: Handle Count erhöht sich

  Alt 29. Jul 2020, 08:19
Das man das Event Handle freigeben muss war mir nicht bekannt.
Steht (ganz unten) in den Remarks zur API-Funktion MSDN-Library durchsuchenCreateEvent:
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
  Mit Zitat antworten Zitat
shebang

Registriert seit: 7. Feb 2020
96 Beiträge
 
Delphi 11 Alexandria
 
#28

AW: Handle Count erhöht sich

  Alt 29. Jul 2020, 09:58
Hat die Benutzung von CreateEvent irgendwelche Vorteile gegenüber TEvent.Create ?
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.017 Beiträge
 
Delphi 12 Athens
 
#29

AW: Handle Count erhöht sich

  Alt 29. Jul 2020, 10:54
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 (Delphi-Referenz durchsuchenTCriticalSection)
Aber da darf man auch gern Delphi-Referenz durchsuchenTMonitor 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)
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests
  Mit Zitat antworten Zitat
venice2
(Gast)

n/a Beiträge
 
#30

AW: Handle Count erhöht sich

  Alt 29. Jul 2020, 16:54
Das man das Event Handle freigeben muss war mir nicht bekannt.
Steht (ganz unten) in den Remarks zur API-Funktion MSDN-Library durchsuchenCreateEvent:
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.
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

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 02:10 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