What are the challenges you face when working across database platforms? Take the survey
Options

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

PeeksPeeks Posts: 5
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 :)

Pywkb.png

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...

iV8j8.png

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?

ia0Qj.png

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?

Comments

  • Options
    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
  • Options
    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
  • Options
    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-
  • Options
    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
Sign In or Register to comment.