none
Possible Memory Leaks RRS feed

  • Question

  • Hi,

    I am having an issue with my newly compiled program.

    It keeps taking up memory till it eventually took up almost all of my memory.

    To check if there is a memory leak, I have run Perfmon.exe and added counters to check for Private Bytes and Bytes in all Heaps.

    But the results show a stable usage with no increments at all.

    It appears that there is no memory leak at all but the memory usage keeps increasing.

    Does anyone have an idea of whats going on?

    Thanks.

    Thursday, February 15, 2018 4:11 AM

All replies

  • Sounds like you have a memory leak.  You know because memory usage keeps increasing.

    I suggest you test parts of your app in isolation.  Try to find the leak.

    Thursday, February 15, 2018 4:22 AM
  • Greetings Koh.

    Without seeing your code, it's a bit difficult to tell.

    The most obvious question is, are you sure there is no legitimate reason for the memory usage to keep rising? For example, do you have any lists of objects that might be filled with millions of entries?

    Perhaps it's happening by accident. You might be meaning to create a list, add some items, clear the list, add some other items, clear the list, and so on, but something is wrong and the "clear the list" part isn't happening.

    Thursday, February 15, 2018 4:26 AM
  • Hello,

     Memory leaks are certainly something to be concerned about. However, in C Sharp vs C++, the

    issue of Garbage Collection is rarely the problem. Your coding could be the result of something as

    simple as not calling Dispose() on Bitmap that are no longer needed. 

     

     Since you have not given great detail about your application and the data requirements, we can

    only guess a solution.   We all understand the need for protecting or prohibited release of code.

     

     But, without seeing or knowing what your application was designed to do then a solution is slim

    if at all from us.

     

     If you are calling C++ via imports, using a DLL from non-Microsoft developers, etc. could be the

    problem.  If none of the previous apply then try changing the mechanics of your code if possible.

     

     Sorry :/

    Thursday, February 15, 2018 4:41 AM
  • Contrary to what seems obvious, it is not likely a memory leak. This question is often asked and I have not seen much (I think no) answers that there is a leak. Windows does clean-ups of memory that is much like the .Net Garbage Collector. Windows does not do the clean-up as quickly and/or frequently as we might expect. So an increase of storage can be totally normal. Search for answers in previous questions.

    If your program is not using unmanaged code then it is probably not a memory leak. I don't mean unmanaged code in managed classes that your program uses but if your program is using classes that use unmanaged code then be sure you are following the documentation of the library.



    Sam Hobbs
    SimpleSamples.Info

    • Proposed as answer by Cor Ligthert Saturday, February 24, 2018 1:40 PM
    Thursday, February 15, 2018 6:13 AM
  • You can use .Net Memory Profiler. As anybody mentioned memory is not cleaned so frequently as you expected. But .NET Memory Profiler can create memory snapshot so it calls garbage collector to clean up before snapshot is created. It is very nice to see if there is some leak or not. 
    Thursday, February 15, 2018 11:36 AM
  • "It keeps taking up memory till it eventually took up almost all of my memory."

    What are you looking at to determine this? Depending upon the tool you are using determines what "type" of memory it is looking at and some tools use the same name for different memory. You have the private bytes in Perfmon which means the memory the app has requested but that isn't necessarily committed yet (and may or may not include shared memory). This should be larger than the committed memory. It is common to request far more memory than you actually use simply because of how most language runtimes work. Note that this memory may never be used and doesn't indicate any issues unless it keeps going up along with the committed memory.

    You also have working set which is the actual memory you're using in the process that is currently paged in. But working set includes memory that may be shared with others so if you're using memory mapped files or whatnot then this may not be representative of just your process. Private working set would be just your memory. This has been, in the past, what Task Manager shows as the memory usage when you look at it. 

    Virtual bytes is the total memory allocated for the process whether it is paged in or not. It can be larger than physical memory because of the page file. If this value is going up you likely have a leak. 

    Note also that .NET allocates memory in chunks (like most languages) but it doesn't release that memory back unless memory constraints kick in. So in a typical .NET app you'll see memory being allocated early on. It may continue to go up as your app starts to load new stuff and finish initializing. After that it tends to level out and go up and down only when your app is doing something. However .NET won't generally free virtual memory until it gets over the memory threshold configured by the runtime. So in a .NET app seeing memory go up but never back down is expected until a certain threshold.  MSDN has an (older) document on some of this and how to look into it.

    You should consider running code analysis on your code. It should help detect any cases where you're using an IDisposable object and not disposing of it. If a .NET app has a leak it is generally because of this. However with the GC running it will eventually get cleaned up anyway. Also look for cases where you're calling the GC directly. This, in my experience, is almost always the wrong thing to do. Finally, look for any cases where you're allocating large arrays. This will eat up memory pretty quick and, if you are keeping references to it around, could result in the array being pushed to gen 3 where it'll stay in memory for quite a while.


    Michael Taylor http://www.michaeltaylorp3.net

    Thursday, February 15, 2018 3:58 PM
    Moderator
  • We had memory leak in application caused by event handler. It is most of cases memory leak. There was object A which has reference to object B which has event handler reference to object A. There was cyclic reference so garbage collector could not clean up it. It is very hard to see and check it. 

    I solved it by .NET Memory Compiler which said me where problem is because there are some calling and reference maps...


    • Edited by Petr B Friday, February 16, 2018 10:32 AM
    Friday, February 16, 2018 10:28 AM
  • Hi Petr
    Thanks for the suggestion.

    Would you happen to know where to get this .NET Memory Compiler?

    Tuesday, February 20, 2018 3:07 AM
  • My mistake, sorry. It is not Compiler but Profiler :) 

    You can download it from https://memprofiler.com/ . It is trial version but if you can try to find memory leak it could be enough. 

    You can create snapshot so you can see which objects are growing in memory.
    • Edited by Petr B Saturday, February 24, 2018 12:24 PM Add some text
    Saturday, February 24, 2018 12:22 PM



  • Sam Hobbs
    SimpleSamples.Info

    Yea they should fire all those persons who do the whole day nothing else than looking if taskmanager present that there is much memory in use. 

    :-)


    Success
    Cor


    • Edited by Cor Ligthert Saturday, February 24, 2018 1:44 PM
    Saturday, February 24, 2018 1:44 PM