none
Receiving unexpected OutOfMemory exceptions RRS feed

  • Question

  • I have a (nearly) released commercial application built in .Net 1.1.  At the high level, it is a protocol proxy.  Needless to say, it creates and uses many sockets.  It is running on a 2003 Std Edition SP1, 2MB memory with 4MB virtual and 2 hyper-threaded XEON CPU’s. and is configured to use server mode GC via the following in the .config file. 

      <runtime>
        <gcServer enabled="true"/>
      </runtime>

    The customer has a release build.  I sent them a debug build one time to check something and it ran much worse.

    It has started getting OutOfMemoryException at one of the customer beta sites.  The customer is reporting that TaskManager is reporting that the application grows to about 500MB (it starts at about 30 or 40 MB).  I have put in some very rudimentary checking in that every time a connection is closed, I log the result from GC.GetTotalMemory.  The values vary from 2.5 MB shortly after startup to a max of 104MB with a normal range of about 20 - 40 MB.  If the value is > 80MB, I force a full collection with GC::Collect(GC::MaxGeneration);  (Putting the force of the full collection in seems to have helped the situation some.)

    At the time of the OutOfMemoryException, the values for TotalMemory are fairly small.  Usually in the 10-20 MB range.

    I believe the difference in the usage reported by TaskManager and TotalMemory can be explained by the memory being allocated by the OS for every open socket.  Other than that and whatever the OS is allocating to handle SSL protocol, there should not be any large non-managed memory allocations.

    There are no EXPLICITLY pinned objects.  Of course, we know that sockets and other such things are pinned and I have calls to other Win32 routines such as SSPI through IJW that as I understand should automatically pin calling and unpin on return so, I should not have anything pinned for a long duration.

    This information tells me that the problem is not really the heap size, but that it must be something else.  My first thoughts are bad code in GC and memory allocation or the nonpaged pool items.  I have not come anywhere near the theoretical maximum number of sockets open.

    I need some direction as to how to figure this one out.  Needless to say, it does not happen here where I stand some small chance of instrumenting and I do not really know enough to tell the customer how to and what to look for.

    Thank you for you time and advice.

    Friday, February 17, 2006 11:29 AM

Answers

  • Hi Roy

    Have you read Rico's Managed Memory Leak blog post?  It has some great tips on how to debug such problems: http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx

    It's possible the OutOfMemory Exceptions are being caused by memory fragmentation due to pinning from the socket APIs.  Is it possible to have your customers upgrade to .NET Framework v2.0?  We've made many improvements with respect to memory fragmentation, and this might help solve your problem.

    Hope that helps

    -Chris

    Monday, February 20, 2006 5:55 PM

All replies

  • Can you terminal serve into the customers computer? In the past when I've had problems that can't be recreated locally, I'll terminal serve, install the Framework SDK and run GUI debug.

    Also in the past TaskManager has not been a very reliable source for looking at memory usage...generally prefer to use perf mon for that.

    Friday, February 17, 2006 3:12 PM
  • Can not RDP.  They only allow Live Meeting or equivalent.  Also this takes days to happen.

    TaskManager may not be reliable, but that is what the customer is relying on and they are convinced that it grows to > 500MB.  That preception is what I have to deal with.

    Friday, February 17, 2006 3:15 PM
  • Hi Roy

    Have you read Rico's Managed Memory Leak blog post?  It has some great tips on how to debug such problems: http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx

    It's possible the OutOfMemory Exceptions are being caused by memory fragmentation due to pinning from the socket APIs.  Is it possible to have your customers upgrade to .NET Framework v2.0?  We've made many improvements with respect to memory fragmentation, and this might help solve your problem.

    Hope that helps

    -Chris

    Monday, February 20, 2006 5:55 PM
  • Thanks for the pointer to the blog and VADump.  I will look at that for sure.

    Unforuntatly, I can not upgrade the application to 2.0.  I made the mistake of beliveing that managed C++ was real and I have several hundred thousand lines of manage C++ code that will not compile under VS 2005 without masive changes.  (So far I have not even been able to get one module to complie and link.)

    Monday, February 20, 2006 6:55 PM