none
,NET MEMORY PROBLEM RRS feed

  • Question

  • Dear All

    I have started to use the CLRPROFILER.

    When I execute my appplycation and I use it. It appears these memory problems a I don't understand where is the problem.

    For example: What's IO.MemoryStream Drawing.Internal.GP or controlNative.ControlNativeView?

    The problems appears in:

    Internal.GPStream - IO.MemoryStream Drawing.Internal.GP

    Finalizer --> Control.ControlNativeWindow

    Pinnig -->System.Object[]

    Could you tell me why the memory is increased?

    I will upload images when it verifies my account

    Sunday, October 14, 2012 9:37 PM

Answers

  • Simply assigning Nothing is not enough for Windows Forms controls, forms, images etc. You have to call Dispose on such objects when you no longer need them.

    Setting something to Nothing can indeed cause the "root" memory to decrease: if there are no more references to that object then the object won't be included in the numbers displayed by the CLR profiler heap graph. But this doesn't mean that the memory is immediately released, the garbage collector must run for that to happen and this is expected behavior.

    Virtual memory is not a very good indicator in this case. Even if you set things to Nothing and/or call Dispose the managed memory won't be released until the garbage collector runs. Even if it runs it may not release all the memory back to the OS and in this case the virtual memory may not decrease.

    From the presented details it's not obvious to me if you have a real problem, except for not calling Dispose.

    Tuesday, October 16, 2012 1:22 PM
    Moderator
  • A memorystream class allocates memory from the Windows Operting system and can grow very large.  You have to make sure you deallocate the memory stream by closing it to make sure you don't end up with a memory leak.  The memorystream when it grows large will also use a hash algorithm.  When using a memorystream you can either specify the intial size or don't specify the intial sizze.  When you specify the intial size then you end up with a fixed size stream.  When you don't specify the size the memory stream will automatically increase in size as required by your appliation, but then you have to close the memory stream to deallocate the memory.

    Memory allocation can cause prblems when the allocation memory buffers become fragmented.  Initially allocated memory when you start PC is continuous.  After you allocated and deallocate different sizes memory a lot of times, the memory buffer beomes fragmented.  When the memory buffer is fragmented it can slow down future memory allocations.  The best solution to the problem is to release the memory by closing the memorystream.


    jdweng

    Monday, October 15, 2012 7:37 AM
  • "The root memory is decrease but the virtual memory not. I don't know what to do."

    I told you above that virtual memory is not a good indicator of a problem. Repeat the open/close form operation a number times and in general try to use the application for some time. If the virtual memory never ever decreases then you might have a problem but until cannot know.

    The simple fact that the memory shown by the CLR profiler decreases is a good indicator that you do not have some sort of memory leak.

    Tuesday, October 16, 2012 1:57 PM
    Moderator
  • Virutual memory would be a temporary file on your system.  I'm not sure where it is located.  Rebooting the PC may dispose the file, sometimes they are in the IE explorer temporary space and get removed when you cdelete your browsing history.  Sometime they are files starting with $ left in a folder.

    jdweng

    Tuesday, October 16, 2012 2:30 PM

All replies

  • A memorystream class allocates memory from the Windows Operting system and can grow very large.  You have to make sure you deallocate the memory stream by closing it to make sure you don't end up with a memory leak.  The memorystream when it grows large will also use a hash algorithm.  When using a memorystream you can either specify the intial size or don't specify the intial sizze.  When you specify the intial size then you end up with a fixed size stream.  When you don't specify the size the memory stream will automatically increase in size as required by your appliation, but then you have to close the memory stream to deallocate the memory.

    Memory allocation can cause prblems when the allocation memory buffers become fragmented.  Initially allocated memory when you start PC is continuous.  After you allocated and deallocate different sizes memory a lot of times, the memory buffer beomes fragmented.  When the memory buffer is fragmented it can slow down future memory allocations.  The best solution to the problem is to release the memory by closing the memorystream.


    jdweng

    Monday, October 15, 2012 7:37 AM
  • That GPStream thing is likely related to GDI+/System.Drawing. You're probably not disposing unused images/controls.

    @Joel Engineer:

    "You have to make sure you deallocate the memory stream by closing it to make sure you don't end up with a memory leak."

    Closing a MemoryStream doesn't release any memory. The only way to release memory is to get rid of all the references to the stream and that's exactly what doesn't happen in his code probably.

    "The memorystream when it grows large will also use a hash algorithm."

    Huh?! Hash? Where and what for? How does that affect memory use?!

    Monday, October 15, 2012 9:24 AM
    Moderator
  • Mike : There are a lot of things that happen in the Windows oeprating System that isn't widely advertised.  I haven't looked at the allocate functionality in years, but at one time it was documented to use hash after the allocation size reached a certain size.

    Are you sure the closing a MemoryStream does dispose of all the resouces like allocated memory?  It should if the buffer size isn't specified.  Don't forget the buffer is different depending if the size is specified in the constructor verses the size not being specified in the constructor.  I was referinig to the case where the size wan't specified which that uses allocated memory rather than a fixed size buffer.


    jdweng

    Monday, October 15, 2012 9:37 AM
  • "There are a lot of things that happen in the Windows oeprating System that isn't widely advertised."

    Yes but I've never ever heard of hashing being used in relation to memory allocation in either Windows or CLR. Anyway I don't see how this could influence the actual memory use.

    "Are you sure the closing a MemoryStream does dispose of all the resouces like allocated memory?"

    Yes, otherwise you couldn't do ToArray() to extract the data from stream.

    " I was referinig to the case where the size wan't specified which that uses allocated memory rather than a fixed size buffer."

    Hmm, the "buffer" is the same in all cases, a byte array. Obviously a byte[] is always fixed size and if the memory stream needs more space then it allocates a larger array and copies the data from the previous array. This behavior can cause fragmentation in the large object heap when the length exceeds 85k but I doubt that OP's problem has somehting to do with fragmentation, it simply looks like memory retention caused by undisposed images.

    Monday, October 15, 2012 9:49 AM
    Moderator
  • Hi,  I'm using the CLR Profiler. I open my exe with the CLR Profiler. When I open several forms the virtual memory is increased and when I open the "Show Heap Now" the memory (root) is increased too. When i close the forms I close all objects and the array I assign Nothing. The memory of root is decreased but the virtual memory not. Could you tell me if it's normal or not? Could you tell me how can i fix?

    Thanks

    Tuesday, October 16, 2012 12:46 PM
  • Simply assigning Nothing is not enough for Windows Forms controls, forms, images etc. You have to call Dispose on such objects when you no longer need them.

    Setting something to Nothing can indeed cause the "root" memory to decrease: if there are no more references to that object then the object won't be included in the numbers displayed by the CLR profiler heap graph. But this doesn't mean that the memory is immediately released, the garbage collector must run for that to happen and this is expected behavior.

    Virtual memory is not a very good indicator in this case. Even if you set things to Nothing and/or call Dispose the managed memory won't be released until the garbage collector runs. Even if it runs it may not release all the memory back to the OS and in this case the virtual memory may not decrease.

    From the presented details it's not obvious to me if you have a real problem, except for not calling Dispose.

    Tuesday, October 16, 2012 1:22 PM
    Moderator
  • I use the Dispose when I close the forms and objects of database connections and I set the array to nothing. I forgot to tell you.

    The root memory is decrease but the virtual memory not. I don't know what to do. 

    Thanks

    Tuesday, October 16, 2012 1:37 PM
  • Tuesday, October 16, 2012 1:53 PM
  • "The root memory is decrease but the virtual memory not. I don't know what to do."

    I told you above that virtual memory is not a good indicator of a problem. Repeat the open/close form operation a number times and in general try to use the application for some time. If the virtual memory never ever decreases then you might have a problem but until cannot know.

    The simple fact that the memory shown by the CLR profiler decreases is a good indicator that you do not have some sort of memory leak.

    Tuesday, October 16, 2012 1:57 PM
    Moderator
  • Virutual memory would be a temporary file on your system.  I'm not sure where it is located.  Rebooting the PC may dispose the file, sometimes they are in the IE explorer temporary space and get removed when you cdelete your browsing history.  Sometime they are files starting with $ left in a folder.

    jdweng

    Tuesday, October 16, 2012 2:30 PM