none
OutOfMemoryException when my library called via COM RRS feed

  • Question

  • A general design pattern we use for applications that generate statements from data files: A statement generator class library is created. It has a couple of properties to set input and output file names, and then a method to generate all of the statements. For testing we create an on-demand windows application which instances, and calls the library via CLR.  In production we have scripts which instance the component and calls the library via COM.  We are making perhaps 4 property value sets, and then making 1 method call. We don't call our generate method for each statement created, but rather, one call to generate all of the statements.

    We have several applications generated in this pattern. A few of them generate perhaps 100,000 to 250,000 pages of statements in the generate call.  We create our own PCL files, directly using SYSTEM.IO.

    NEVER when run interactively, invoking our library via CLR do we ever have any problem.

    When run in production, these applications will fail after about 1 hour wall time with System.OutOfMemoryException.

    Does .NET runtime memory management (GC) operate DIFFERENTLY when a class library is invoked via a COM interface, as opposed to a CLR interface?  If not, then what other things to consider?

    VS 2008, VB.net, Framework 3.5
    Production computer is running Windows Server 2003, release 2, SP 2
    Its an Intel dual core, 4 GB RAM (Dell rackmount server 1950)


    Online Data Processing, Inc. - Spokane, WA
    Monday, October 4, 2010 3:46 PM

Answers

  • Sometime later, but the answer is found.  When used via COM we are invoking the component via a batch processor windows service. Windows services have a smaller heap allocation to them than do interactive windows processes.  When we run the component interactively via a "test" windows application that uses CLR interface, then it has probably 6 times more heap available.

    Found all this out when I couldn't get any more services to run on a server, and playing around with the heap allocation controls which allow more or fewer services to be run.


    Lee Gillie, CCP Online Data Processing, Inc. - Spokane, WA

    • Marked as answer by Lee Gillie Tuesday, May 8, 2012 8:59 PM
    Tuesday, May 8, 2012 8:59 PM

All replies

  • Definitely. The CLR call is managed. It knows when to reclaim memory that is not being used. COM on the other hand can't tell the CLR that it is no longer using the resource, so they pile up and eventually take down the machine. You should call COMReleaseUnmanagedResources (don't quote me on the exact method name) to release your objects when you are done with them. And you'll need to call it on each "." e.g.,

    unmanaged obj = new object();

    someotherobj obj2 = obj.getsomething();

    release obj2

    release obj

    basic pattern, obviously this won't comile!

    Wednesday, October 6, 2010 2:21 AM
  • You must be referring to ReleaseComObject?

    I found this in depth discussion:

    http://blogs.msdn.com/b/cbrumme/archive/2003/04/16/51355.aspx

    I believe you are describing what to do when you instance COM objects in your managed code, and you need to release them. Our situation is that we are instancing a CLR object via COM INTEROP from VBScript.  When we do we run out of memory. When we instance from CLR and do the same work, we do not run out of memory.

    My original question then: Does .NET runtime memory management (GC) operate DIFFERENTLY when a class library is invoked via a COM interface, as opposed to a CLR interface?  If not, then what other things to consider?
    Lee Gillie, CCP Online Data Processing, Inc. - Spokane, WA
    • Marked as answer by Lee Gillie Tuesday, May 8, 2012 8:59 PM
    • Unmarked as answer by Lee Gillie Tuesday, May 8, 2012 8:59 PM
    Thursday, October 7, 2010 8:10 PM
  • Sometime later, but the answer is found.  When used via COM we are invoking the component via a batch processor windows service. Windows services have a smaller heap allocation to them than do interactive windows processes.  When we run the component interactively via a "test" windows application that uses CLR interface, then it has probably 6 times more heap available.

    Found all this out when I couldn't get any more services to run on a server, and playing around with the heap allocation controls which allow more or fewer services to be run.


    Lee Gillie, CCP Online Data Processing, Inc. - Spokane, WA

    • Marked as answer by Lee Gillie Tuesday, May 8, 2012 8:59 PM
    Tuesday, May 8, 2012 8:59 PM