Trying to figure out the process to debug these leaks...

Memory profiling for .NET developers

Moderators: StephenC, Alex.Davies, AndrewH, melvyn.harbour

Trying to figure out the process to debug these leaks...

Postby Peeks » Tue Sep 21, 2010 5:07 am

Hi guys,

I've just found your product and so I'm giving it a trial run. We develop winform apps and this is one of our smaller products we thought we would test.

We're trying to understand how we should be using the product to help us find poor code that results in memory leaks. So, can someone confirm that our understanding about how we're using the product, is right?

----

First up, it just parses txt files and inserts them into a database. Running this quickly gets the process size up to a Gig+ It's obvious that something isn't getting released, etc. Simple candidate to start off :)

Second, we're using StructureMap for dependency injection. NLog for logging. Entity Framework for database stuff (with all DB stuff turned off, for this sampling).

In our initial profile, I took a baseline snapshot after the app started (30Mb process size .. no actions taking place). Ran it for a min until it hit 100Mb .. took a second snapshot and stopped. I got this idea from the slideshow help files :)

Image

So it's pretty informative that - first up - it saying i have a lot of strings that aren't getting released? and then there some other stuff which i _think_ is related to NLog?

So i'm delving deaper and deaper to find some of these things.... to confirm what's going on...

Image

This class list once more confirms some stuff... Strings are going mad .. and once more lots of NLog stuff :( hmmm... It's also interesting to see some Net.Socket stuff in there. I think i've got NLog setup to work async? i wonder if this is why we're seeing lots of Socket stuff...

Now, this is where we're starting to get stuck.

This image shows us the Live Size (in bytes) of the objects that are taking up memory, right? If i'm looking at the string class, it's about 9.5MB. I can confirm this by going to the Class reference explorer. But my process is running at around 100Mb. so i don't get what I'm doing wrong.

Secondly, we seriously don't understand why NLog would not be releasing all this info. Is there a way we can see what is stopping it from being released?

One thing one of the team members suggested was that the Retention Graph might be the key here : what is keeping a hold on the strings?

Image

so we checked this out. It's pretty damn kewl how this product allows us to drill down from top to bottom .. asumming we're using the product correctly.

So from here we're not sure what we can do .. suppose to do? Have we even used this right?

We might start another analysis with the Async turned off to compare things....

Thoughts anyone?
Peeks
 
Posts: 3
Joined: Tue Sep 21, 2010 4:41 am

Postby StephenC » Tue Sep 21, 2010 11:40 am

This tutorial is probably the best one to give you a good idea how to use the tool:

Part 1:
http://www.youtube.com/watch?v=yZ8dC5nlhiY

Part 2:
http://www.youtube.com/watch?v=bcM6DoCV ... re=related

Regards,

Stephen
StephenC
 
Posts: 306
Joined: Mon Oct 15, 2007 9:18 am
Location: Cambridge

Postby StephenC » Tue Sep 21, 2010 12:45 pm

Using the filters on the left hand side of the application will be very useful in identifying objects that are responsible for the leaks.

There's also a chance that large object heap fragmentation is contributing to your problems.

http://bit.ly/b9z0uu

Stephen
StephenC
 
Posts: 306
Joined: Mon Oct 15, 2007 9:18 am
Location: Cambridge

Postby Peeks » Wed Sep 22, 2010 2:25 am

Thanks StephenC for the reply.

I already checked out those YT vids before so I could get an idea about how to use the product. I suppose I was just double checking that we were going through the process right.

The biggest take away item from the vids was from vid #2 .. about how it said we need to cut a reference to an object so the hierarchy can get GC'd.

Looking at the Renention graph, i was getting so confused because all the data kept pointing back to NLog. The strings were NLog related (connection strings, etc). The Net Socket stuff was also NLog related. It's like it was not releasing some network level code. Our assumption: NLog is ok, but my code is not. After all, NLog is a popular application that is being used by many, many people which suggests it's pretty stable, etc.

I kept thinking .. how can i make it so that those NLog delegates (which Memory Profiler 6 was showing me) could get disconnected/cut?

Until I thought for a second: is anyone else having a memory leak issue with NLog...

google points me to: http://github.com/jkowalski/NLog/commit ... d363ee4b95

Downloaded the latest nightly build and viola! memory leak gone.

Awesome work RedGate :) I would never have thought the error lied with the old(er) NLog dll I was using.

Cheers :)

-PK-
Peeks
 
Posts: 3
Joined: Tue Sep 21, 2010 4:41 am

Postby StephenC » Wed Sep 22, 2010 10:49 am

Memory leaks in 3rd party software is relatively common.

Does NLog come with the source code? From the reference graph the objects with bolded black text indicate so. Is this correct?

At any rate, glad you have managed to get rid of the memory leak. They can be very annoying to say the least.

S
StephenC
 
Posts: 306
Joined: Mon Oct 15, 2007 9:18 am
Location: Cambridge


Return to ANTS Memory Profiler Previous Versions

Who is online

Users browsing this forum: No registered users and 0 guests