CreateThread compiliert mit /clr verursacht Handle Leak

thesnoopy

Hi Leute,

danke für eure antworten.
Leider löst beides das Problem nicht.

@Knuddelbaer: Das ist beabsichtigt, hat aber auch keine negativen Konsequenzen. Der Handle kann ruhigen Gewissens zerstötrt werden, da Windows interne Handler benutzt. Der Handler wird nur zurückgegeben, damit der aufrufende Thread/Prozess den erzeugten Thread kontrolieren kann.

@Jochen: Leider löst diese Variante das Problem auch nicht.

Nochmal vielen Dank für die Antworten, habt Ihr noch weitere Ideen?

Gruß,

Carsten

Jochen Kalmbach

Wie hast Du denn das Leak festgestellt???

Ich hab das mal laufen lassen und es sah wirklich sehr suspekt nach leak aus.
Es hat aber mit dem GC zu tun.
Ruf einfach mal GC::Collect auf und dann siehst du das es sich normalisiert.

thesnoopy

@Jochen
Ich habe mich gewundert, warum mein Programm nach ein Paar Stunden das zeitliche segnet, Also habe ich mir mit dem Microsoft Process Explorer den Speicherverbrauch und die Anzahl der Handles anzeigen lassen. Dann ist mir aufgefallen, dass bei jedem CreateThread 5 "suspekte" Handles erstellt werden. Weiterhinn nimmt der Speicherverbrauch kontinuierlich zu.

@Gator
Kann ich dass in unmanaged c++ Code aufrufen? wenn ja, welcher include? Gibt es vielleicht noch eine elegantere Lösung?

Gruß,

carsten

Ich denke man sollte CreateThread überhaupt nicht direkt verwenden.

http://blog.m-ri.de/index.php/2007/11/28/createthread-und-die-crt/

thesnoopy

@nn

Danke für den Post. In meinem Programm benutze ich auch _beginthread(). Allerdings hat das nichts mit meinem Problem zu tun, da beide Funktionen gleich reagieren.

Ich habe, um das Problem zu umgehen, die Funktionen die auf die CLR zugrafen in eine seperate Library ausgelagert. Somit konnte ich den Programmteil, der die Thread erzeugt, ohne /clr kompilieren. Und siehe da, das Leak ist weg.

Allerdings interessiert mich trotzdem, was da schief läuft (reine Neugier). Hat jemand ne Idee, was da genau passiert?

Gruß,

Carsten

WeaponX2007

@thesnoopy:

Ja das konnte ich mir denken das es da nicht vorkommt.

Die IJW invocation wrappt ja in dem Fall deine Funktionsaufrufe in die lib und nicht mehr nur den CreateThread Aufruf.
Ich denke also das es etwas mit der Art und Weise zu tun hat wie das "thunking/marshaling" von CreateThread vonstatten geht. Ich denke sogar das es sich dabei um Managed resources (wrapped) handelt, die aber speziell behandelt werden, und nichtmal in einem "profiler" auftauchen, eben mit Collect, jedoch nicht mit einfachem Speicherdruck, wieder freigegeben werden. (Komisch!)

Bezüglich deiner Frage ob und wie man das GC::Collect einbindet, ist die Antwort: Es ist ja mit /clr kompiliert, also hast du vollen Zugriff auf das .net framework. Du brauchst also nur die Reference auf die assembly (System) setzen und GC::Collect aufrufen.

Für mich ist das sehr interessant. Ich habe schon einige "qualifizierte" Leute zu diesem Thema angekurbelt und warte auf deren Feedbacks. (Werde natürlich diesbezüglich diesen Thread weiter mit infos "beposten")

WX

Jochen Kalmbach

Kannst Du mir mal ein Beispielprojekt zukommen lassen?

thesnoopy

Jochen Kalmbach schrieb:

Kannst Du mir mal ein Beispielprojekt zukommen lassen?

Dazu brauche ich noch die Emailadresse. Schick mir einfach eine E-Mail an thesnoopy@web.de.

C-Chris

@Gator
Kann ich dass in unmanaged c++ Code aufrufen? wenn ja, welcher include? Gibt es vielleicht noch eine elegantere Lösung?

Nein das musst du mit der using-Klausel machen:

#using<System.dll>

Keine Ahnung ob das noch up-to-date ist