 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / CLR / December 2003Leaking GCHandles?
My .NET Windows Service seems to be leaking GCHandles... after a days of running PerfMon shows 1,800,000 (roughly) GCHandles in use and it climbs steadily as my application runs. My app. makes heavy use of Interop. My understanding of a GCHandle is it's basically a pointer to a managed resource for use by nonmanaged code. Is that correct? Where do I start looking in the code for what is leaking GCHandles? > My .NET Windows Service seems to be leaking GCHandles... after a days > of running PerfMon shows 1,800,000 (roughly) GCHandles in use and it [quoted text clipped - 5 lines] > > Where do I start looking in the code for what is leaking GCHandles? I'd say you start looking in your code if you have implemented the Dispose Methods correctly and if you are really calling them. Seems like your unmanaged resources aren't cleaned... Greets Peter  Signature------ooo---OOO---ooo------ Peter Koen - www.kema.at MCAD CAI/RS CASE/RS IAT ------ooo---OOO---ooo------ Well it appears that most if not all of the leaking GCHandles are related to scripts that I executed using the Vsa engine in a separate AppDomain. So I don't understand where unmanaged resources are coming into this. > > My .NET Windows Service seems to be leaking GCHandles... after a days > > of running PerfMon shows 1,800,000 (roughly) GCHandles in use and it [quoted text clipped - 20 lines] > > ------ooo---OOO---ooo------ > Well it appears that most if not all of the leaking GCHandles are > related to scripts that I executed using the Vsa engine in a separate > AppDomain. So I don't understand where unmanaged resources are > coming into this. Well, VSA is unmanged -> GCHandles for every VSA Objekt that isn't cleaned up. But there is also another memleak (known bug), maybe you've run into this: When you are creating and destroying AppDomains by your own then everytime a few kb of memory are lost and one GC Handle pointing there can't clean up. Yes, that is a known bug and afaik it will be cleared with the next Version of .NET Greets Peter Signature------ooo---OOO---ooo------ Peter Koen - www.kema.at MCAD CAI/RS CASE/RS IAT ------ooo---OOO---ooo------ > But there is also another memleak (known bug), maybe you've run into this: > When you are creating and destroying AppDomains by your own then everytime [quoted text clipped - 3 lines] > Yes, that is a known bug and afaik it will be cleared with the next Version > of .NET Yes I do know about that. I just didn't know that that was what could leak GCHandles. We've done everything possible to minimize the memory leak but the next step is to move all this VSA processing to a separate process that will end after each run so memory will be reclaimed. Good to hear that the next .NET Framework will clean up this memory issue. Where did you get that information from? You might want to contact Microsoft. They probably have a hotfix that can be applied in the interim. http://support.microsoft.com/support/misc/kblookup.asp?id=817723 I have been supplied with hotfixes for 1.0 and 1.1 memory leaks. HTH; Eric Cadwell http://www.origincontrols.com Well guess what. My idea for a work-around was to move the Vsa script processing out of the Windows Service to a separate executable on the idea that when the processing is complete then the executable ends and the memory/GCHandles are returned. But it doesn't work! Apparently the GCHandles stay leaked as long as the CLR is running? In other words, it basically requires a reboot. Can anyone confirm or shed more light on this? And will .NET 2.0 truly fix this? This problem essentially renders the .NET scripting engine (or any dynamically generated assemblies) un-usable for this type of scenario. I really need a .NET scripting engine because scripts must be able to call .NET functions that I provide. Nothing to do with a bug, this is a feature. Here is what is happening: The VSA engine compiles scripts in an in memory assembly. This assembly is used to extract types and create new objects. Two configurations: 1. You load the vsa engine in your main AppDomain (this is the case if you don't create a new AppDomain, don't know what an AppDomain is). In that case, there's nothing else to do than keeping reading and try to google or msdn a bit. 2. You load the vsa engine in another AppDomain. You did half of the work. You create your object, and pass it back as a reference to your main AppDomain. to be able to traverse the AppDomain, you go through either references (MarshalByRefObject inherited classes) or serialization (anything else), and on the other side (your main AppDomain), the dll is loaded. That's what I call the viral dll loading problem. In this exact case, when you unload your second AppDomain, the code is still compiled in memory in the first AppDomain and never released, and as such your GCHandles are not released. My advice: You don't really need VSA anyway, reflection and dlls are enough. Stay away from CreateInstanceAndUnwrap. Learn to love MBV objects, and ObjRef. VSA was completely dropped so there's no reason to keep on trying. SignatureSebastien Lambla http://thetechnologist.is-a-geek.com/blog/ > Well guess what. My idea for a work-around was to move the Vsa script > processing out of the Windows Service to a separate executable on the idea [quoted text clipped - 10 lines] > really need a .NET scripting engine because scripts must be able to call > .NET functions that I provide. > My advice: You don't really need VSA anyway, reflection and dlls are enough. My web application allows users to create little VB.NET scripts to execute. That is currently done using the Vsa engine. How could I do this using reflection and DLLs while avoiding the GCHandles or memory leakage problems? I guess I could compile all of the scripts into one assembly and then execute them individually. But really I'll always have the same problem of leakage won't I? > Stay away from CreateInstanceAndUnwrap. Learn to love MBV objects, and > ObjRef. VSA was completely dropped so there's no reason to keep on trying. What do you mean "VSA was completely dropped"??? > How could I do this using reflection and DLLs while avoiding the GCHandles > or memory leakage problems? I guess I could compile all of the scripts into > one assembly and then execute them individually. But really I'll always > have the same problem of leakage won't I? As I said, the only way to get no memory leak is to compile it into a file based assembly on disk, load it in a separate appdomain and don't ever send the references to the types defined in the script to the main appdomain, only base types and interfaces. Then by shutting down the appdomain, you won't have anything leaking. > What do you mean "VSA was completely dropped"??? Well, VSA was an attempt at doing VBA with .net languages. Frankly, this project looks a lot like it's absolutely going nowhere in the foreseeable future, so you'd be better off not using all the VSA interfaces and doing the compilation model yourself, while microsoft come up with something more usable. SignatureSebastien Lambla http://thetechnologist.is-a-geek.com/blog/ From everything I've read the problem isn't Vsa per se, it's that assemblies cannot truly be fully unloaded. That's a problem where you're using Vsa or Reflection.Emit or whatever. > As I said, the only way to get no memory leak is to compile it into a file > based assembly on disk, load it in a separate appdomain and don't ever send > the references to the types defined in the script to the main appdomain, > only base types and interfaces. Then by shutting down the appdomain, you > won't have anything leaking. Sure, but using VSA just increase the risk of contaminating your main assembly with code you compile on the fly, which is a bad thing. As long as you're cautious, an assembly can be and will be fully unloaded when you unload its host AppDomain SignatureSebastien Lambla http://thetechnologist.is-a-geek.com/blog/ > From everything I've read the problem isn't Vsa per se, it's that assemblies > cannot truly be fully unloaded. That's a problem where you're using Vsa or [quoted text clipped - 6 lines] > > only base types and interfaces. Then by shutting down the appdomain, you > > won't have anything leaking. Are you running on a multi CPU box? I am asking because the perfmon counter for handles has a bug and it will drift when 2 or more CPUs add handles concurrently. >-----Original Message----- >My .NET Windows Service seems to be leaking GCHandles... after a days of [quoted text clipped - 8 lines] > >. No, single CPU on our development machines and one test server. > Are you running on a multi CPU box? I am asking because > the perfmon counter for handles has a bug and it will [quoted text clipped - 17 lines] > > > >. Here is a suggestion from one of our support engineer: On v1.1 you can attach windbg to the running process, and load the CLR extension dll SOS.dll. Run the command ! sos.objsize with no parameters and that will list all the GCHandles and what they point to. Seeing the type of the object kept alive by the handle may be sufficient to identify the leak. >-----Original Message----- >My .NET Windows Service seems to be leaking GCHandles... after a days of [quoted text clipped - 8 lines] > >. Thanks for the suggestion, we'll try it. We haven't move to .NET 1.1 yet but will be doing so in the coming weeks, finally. One question on the GC Handles value in performance monitor. On one test I was doing it climbed climbed climbed (it was over 130,000,000 when I stopped) but memory usage never grew and stayed relatively flat. According to the "explain" button the GC Handles value is the "in use" value but it seems more like its just a total of how many have been created. How could 130,000,000 actually be in use without chewing up lots of memory? Does each GC handle consume 4 bytes of memory or more? > Here is a suggestion from one of our support engineer: > On v1.1 you can attach windbg to the running process, and [quoted text clipped - 21 lines] > > > >. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.