How to break reference chain (GC Handle)->(System.Object)
dmd1214
Posts: 20
I'm stuck on resolving a leak, and thougth I'd see if you all had any tips.
When I perform a certain function (which I do twice with a snapshot in between to filter out expected cache) I see about 4000 New objects of type "System.Object". Through the object graph, I see the large majority are held only by "GC Handle".
These objects are not on the finalizer queue.
Is there a way to see what instantiated these objects? If not, is this an expected feature? Are there any other tips you might have for me on this issue? I feel like I'm misunderstanding some things. If GC Handle is the only reference to an object, should it not be collected?
Thanks in advance.
When I perform a certain function (which I do twice with a snapshot in between to filter out expected cache) I see about 4000 New objects of type "System.Object". Through the object graph, I see the large majority are held only by "GC Handle".
These objects are not on the finalizer queue.
Is there a way to see what instantiated these objects? If not, is this an expected feature? Are there any other tips you might have for me on this issue? I feel like I'm misunderstanding some things. If GC Handle is the only reference to an object, should it not be collected?
Thanks in advance.
Comments
the most common reason for this is that it's an unmanaged leak and we cannot track that so it would show up as GC Handle. Objects which have also been pinned would also have GC handles keeping them in memory.
One way of testing the unmanaged hypothesis (if it even needs testing) would be to go the Advanced Filters tab in AMP5.
There you will see "Kept in memory only by GC roots of type:"
There are a bunch of options there - one of them is COM+ which I think is unchecked by default. If you actually check that an uncheck the rest and the objects you are referring to still appear it would seem to indicate that there's an unmanaged leak.
I'm assuming that when you create a Class Reference graph for the particular Class you are interested in, the largest % of references are coming from GC Handle?
Stephen
I ended up finding the leak, but it was kind of painful (I'm not familliar at all with the code). For posterity, here's the faulty code:
// This leaks 3 instances of Object
object obj1 = new object();
object obj2 = new object();
object obj3 = new object();
myComObject.GetData(1, ref obj1, ref obj2, ref obj3;
// This does not leak
object obj1 = null;
object obj2 = null;
object obj3 = null;
myComObject.GetData(1, ref obj1, ref obj2, ref obj3;
I'm not precisely sure what's happening here. I guess the obj's loose their GC reference when their pointers get reassigned within the com code... but just guessing really.
One reason I'm posting this is for a feature request. This was pretty painful to locate. I had to sprinkle web session end and termination code throuout the code to pinpoint the faulty lines. It would have been very nice to be able to identify the line of code that instaniated the leaked objects. I could have swarn I've seen that feature before in 4.x... but if not, I know i've seen it in other products.
Anyhow, I still LOVE your product and support... just thought I'd give some feedback.
really glad you found the problem and thanks for posting the information. I'm sure it will help other people in future.
We used to record allocation stacks with the previous version. As you have probably noticed we completely started again with the Memory Profiler and in most situations having the references to an object are enough to identify where the culprit is. We did this primarily because we wanted the fastest memory profiler out there and the cost of recording allocation information is really detrimental to profiler speed.
There are however exceptions and I think this would probably be one of them when the additional allocation information would have provided some useful additional information. Often this isn't the case because the leak is caused by an unknown reference to an object keeping it in memory - not what allocated the object. We will be adding the ability for a user to choose to record allocation stacks in a future version but this will decrease the speed of profiling if selected and in large applications may not lead to a very pleasant end experience.
Glad you are finding the tool still useful and i'll pass your comments on to the team. Any other feedback or questions then just get in touch.
All the best,
Stephen
Is there any update on this feature? I'm currently running AMP 5.2.0.49 Standard Ed. and desperately need this feature for my Fortune 50 client.
Thanks!
we have been working on version 6 of the performance profiler for the last 10 months which has just been released so most of our attention has been firmly targeted at that.
We have managed to work on the memory profiler as well and just put our first EAP build live this morning. The two main features however are attach to a running process and Silverlight profiling.
http://www.red-gate.com/MessageBoard/vi ... .php?f=122
We are now sitting down to discuss V7 of the memory profiler but I really can't say anything other than that because no decisions have been made. Obviously the only thing I can say is that it won't appear in the V6 which is coming over the next couple of months.
Regards,
Stephen
Thanks for your prompt reply
I'm confused by your first and last statements which seem to contradict each other...
You first said that v6 has been released but then say it will be coming out in the next couple of months.
Is v6 available now for use?
so just to clarify - our new Performance Profiler V6 was just launched last week.
The upcoming Memory Profiler V6 has just gone into the early access stage (see link for EAP forum), which you can access now and try each new build as they are released until the final release.
Once the Memory Profiler V6 is officially released in a few months we will then start working on the Memory Profiler V7.
Hope that clarifies things,
Stephen