ref string[] memory leak with NET/COM interop

Question

I recently found a very strange (to me) memory leak for an IEnumString COM object used from C#. Specifically, calling the IEnumString.Next method using a string array that already contained values resulting from a previous call caused a memory leak.

IEnumString looked like this on C# side:

    [InterfaceType(1)]
[Guid("00000101-0000-0000-C000-000000000046")]
public interface IEnumString
{
    void Clone(out IEnumString ppenum);
    void RemoteNext(int celt, string[] rgelt, out int pceltFetched);
    void Reset();
    void Skip(int celt);
}

Calling the RemoteNext (Next) method like this caused a leak, which was verified by running it repeatedly for a long time and seeing the "Private Bytes" counter rise without end.

string[] item = new string[100]; // OBS! Will be re-used for each call!
for (; ; )
{
    int fetched;
    enumString.RemoteNext(item.Length, item, out fetched);
    if (fetched > 0)
    {
        for (int i = 0; i < fetched; ++i)
        {
            // do something with item[i]
        }
    }
    else
    {
        break;
    }
}

But creating a new string item[] array for each call somehow made the leak disappear.

for (; ; )
{
    int fetched;
    string[] item = new string[100]; // Create a new instance for each call.
    enumString.RemoteNext(item.Length, item, out fetched);
    if (fetched > 0)
    {
        for (int i = 0; i < fetched; ++i)
        {
            // do something with item[i]
        }
    }
    else
    {
        break;
    }
}

What is it that goes wrong in the first case? I guess what happens is that the COM memory allocated for the rgelt argument of IEnumString.Next, which should be freed by the caller, somehow is not.

But the second case is strangely working.

Edit: For some additional information, this is what the "implementation" of RemoteNext method looks like in ILDASM and .NET Reflector.

.method public hidebysig newslot abstract virtual 
        instance void  RemoteNext([in] int32 celt,
                                  [in][out] string[]  marshal( lpwstr[ + 0]) rgelt,
                                  [out] int32& pceltFetched) runtime managed internalcall
{
} // end of method IEnumString::RemoteNext



[MethodImpl(MethodImplOptions.InternalCall, MethodCodeType=MethodCodeType.Runtime)]
void RemoteNext(
[In] int celt, 
[In, Out, MarshalAs(UnmanagedType.LPArray, ArraySubType=UnmanagedType.LPWStr, SizeParamIndex=0)] string[] rgelt, 
out int pceltFetched);

Edit 2: You can also make the leak appear in the second non-leaking case by simply adding a string value to the string array (containing only null values) before calling RemoteNext.

string[] item = new string[100]; // Create a new instance for each call.
item[0] = "some string value"; // THIS WILL CAUSE A LEAK
enumString.RemoteNext(item.Length, item, out fetched);

So it seems the item array must be empty for the marshaling layer to correctly free the un-managed strings copied to it. Even so, the array will return the same values, i.e. having a non-empty array does not cause wrong string values to be returned, it just leaks some.

Watch out for synthetic tests, the kind that run the same code snippet millions of times. Use Perfmon.exe and observe the number of garbage collections for your test process. COM uses unmanaged memory, it doesn't put a lot of pressure on the GC. — Hans Passant
– Hans Passant, Commented Apr 14, 2011 at 12:16
It's not a synthetic test, I did not run only the displayed code snippet, but the whole program segment it was used in. (Which is a small test application that retrieves the namespace (branches and leafs) of a server application and simply prints them out. This is done over and over. If left running the with the first code snippet the process will pretty soon consume hundreds of MBs memory, while with the second it will stabilize at about 20MB). — Niklas Bäckman
– Niklas Bäckman, Commented Apr 14, 2011 at 13:45
I also checked the GC heap memory use with Process Explorer, it did not consume much memory in the either case, so I'm pretty confident it was un-managed COM memory that was leaked. — Niklas Bäckman
– Niklas Bäckman, Commented Apr 14, 2011 at 13:49

Eddy · Accepted Answer · 2011-04-20 00:11:56Z

1

IEnumString - it's only an interface. What's the underlying COM object? It's the main suspect.

Look at the unmanaged declaration of IEnumString:

HRESULT Next(
  [in]   ULONG celt,
  [out]  LPOLESTR *rgelt,
  [out]  ULONG *pceltFetched
);

As you see, the second parameter rgelt is just a pointer to an array of strings - nothing especial, but when you do managed call

string[] item = new string[100]; // Create a new instance for each call.
item[0] = "some string value"; // THIS WILL CAUSE A LEAK
enumString.RemoteNext(item.Length, item, out fetched);

it seems your string in item[0] is converted to LPOLESTR which is not freed properly. Therefore try this:

string[] item = new string[1];
for (; ; )
{
    int fetched;
    item[0] = null;
    enumString.RemoteNext(1, item, out fetched);
    if (fetched == 1)
    {
       // do something with item[0]
    }
    else
    {
        break;
    }
}

answered Apr 20, 2011 at 0:11

Eddy

7915 silver badges4 bronze badges

Sign up to request clarification or add additional context in comments.

1 Comment

Niklas Bäckman Over a year ago

Yes, you're right of course! I did not consider that the marshalling layer would convert the managed strings already existing in the item (rgelt) array into unmanaged COM memory needing to be freed. The fault is not with the IEnumString implementation object though, the rgelt parameter is clearly defined as an [out] paramater, so it should not have to free any memory for it. It's just that this "out-info" is lost on the .NET side so there's no warning or error when the caller does wrong. Guess it's best to always use wrappers for COM interops, even when they look like "real" NET citizens!

Collectives™ on Stack Overflow

ref string[] memory leak with NET/COM interop

1 Answer 1

1 Comment

Your Answer

Linked

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

1 Comment

Your Answer

Sign up or log in

Post as a guest

Linked

Related