9

I am writing writing an API in COM in C++, and also writing a program which consumes this API in C#. My question is about BSTR memory management semantics when passing BSTRs into COM functions. Say my IDL looks like:

HRESULT SomeFunction([in] BSTR input);

Currently this function is implemented like this:

HRESULT SomeFunction(BSTR input) {
    // Do stuff ..., then:
    SysFreeString(input);
}

When I call it from C# with something like SomeFunction(myString), will C# generate something like this (pseudocode):

myString = SysAllocString("string");
SomeFunction(myString);

Or rather like this:

myString = SysAllocString("string");
SomeFunction(myString);
SysFreeString(myString);

That is, does C# free the BSTR that it generates to marshal to the COM interface, or should I free it inside my function? Thanks!

fyhuang
  • 2,147
  • 5
  • 21
  • 24

2 Answers2

15

From Allocating and Releasing Memory for a BSTR:

When you call into a function that expects a BSTR argument, you must allocate the memory for the BSTR before the call and release it afterwards. ...

So don't free it if it is an input parameter. C# (and any other runtime that uses COM objects) must respect the COM convention for managing memory pass in and out of COM objects, and must therefore manage the memory for the string if it is an input parameter. Otherwise, how would a COM object know that it is being called from C# or some other language runtime?

Additional google-fu turned up this: Marshaling between Managed and Unmanaged Code

... Regarding ownership issues, the CLR follows COM-style conventions:

  • Memory passed as [in] is owned by the caller and should be both
    allocated by the caller and freed by the caller. The callee should
    not try to free or modify that memory.
  • Memory allocated by the callee and passed as [out] or returned is owned by the caller and should be freed by the caller.
  • The callee can free memory passed as [in, out] from the caller, allocate new memory for it, and overwrite the old pointer value, thereby passing it out. The new memory is owned by the caller. This requires two levels of indirection, such as char **.

In the interop world, caller/callee becomes CLR/native code. The rules above imply that in the unpinned case, if when in native code you
receive a pointer to a block of memory passed to you as [out] from
the CLR, you need to free it. On the other hand, if the CLR receives
a pointer that is passed as [out] from native code, the CLR needs to
free it. Clearly, in the first case, native code needs to do the
de-allocation and in the second case, managed code needs to do
de-allocation.

So the CLR follows the COM rules for memory ownership. QED.

MSN
  • 53,214
  • 7
  • 75
  • 105
  • 1
    This answer has nothing to do with what the CLR automatically does for interop, which is all the OP is asking about. – ildjarn Aug 11 '11 at 23:38
  • @ildjarn: on the contrary, it exactly answers the OP's question. – Cheers and hth. - Alf Aug 11 '11 at 23:56
  • @Alf : Stating the correct answer for the wrong reasons and with the wrong context and links is not really "correct". – ildjarn Aug 11 '11 at 23:57
  • @ildjarn: let me say it like this, you don't understand. unfortunately, what is there to understand is at the level of 2+2=4. no simpler explanation is possible, so i shall not discuss it further with you, only encourage you to think (and i've done a fair amount of interop, if you're wondering). – Cheers and hth. - Alf Aug 11 '11 at 23:58
  • 1
    @Alf : The fact of the matter is that documentation describing manual COM memory management is irrelevant to a question regarding what the CLR _might or might not do on your behalf_. I.e., the question is about CLR COM marshaling, and this answer is not. – ildjarn Aug 12 '11 at 00:05
  • Answering a question about what do you need to do in C# with a link about a construct that only exists in C++ is not valid. (And I've done a fair amount of interop, if you're wondering) – Kyle W Aug 12 '11 at 00:19
  • What a strange argument. How is the called function supposed to know that it got called from the CLR? – Hans Passant Aug 12 '11 at 01:23
  • @Hans, apparently enough people think it's magically handled for you in spite of someone else calling into a COM interface. – MSN Aug 12 '11 at 04:08
  • @ildjarn, why does the CLR get to use different rules for marshalling data to a COM object than the rest of the world? – MSN Aug 12 '11 at 04:10
  • @MSN : The same reason the CLR exists in the first place -- to make programmers' lives easier. If something is tedious and error prone, I don't see why the CLR wouldn't/couldn't do it on your behalf. – ildjarn Aug 12 '11 at 04:11
  • @ildjarn, how are legacy (pre CLR) COM components supposed to know they are being invoked by the CLR and have to follow different rules about memory ownership? (PS, the answer is already publically documented.) – MSN Aug 12 '11 at 04:18
  • @MSN : Now you're begging the question. Downvote the question if you think it's that obvious -- many, especially those who _only_ know .NET, clearly don't. – ildjarn Aug 12 '11 at 04:23
  • 1
    @ildjarn, the question is whether to free in parameters in the COM interface or not. The answer is no, because the CLR uses the COM conventions for memory ownership of parameters. In fact, this is the actual question: "That is, does C# free the BSTR that it generates to marshal to the COM interface, or should I free it inside my function? Thanks!" – MSN Aug 12 '11 at 04:30
  • @MSN : Not coincidentally, that's exactly what I think; and again I say, this answer -- as it was when this discussion started, pre-edit -- did not answer that question. – ildjarn Aug 12 '11 at 05:29
  • 1
    The CLR manages the memory provided through COM+, no? This question was about what you need to do in C#. In C#, would you be required to free an out parameter? The CLR would do that for you, no? If answers are yes, no, yes - the comments about CLR and COM+ memory management are useless, because they don't answer the question about C#. QED – Kyle W Aug 12 '11 at 18:10
  • @Kyle, read the question. The actual question is "That is, does C# free the BSTR that it generates to marshal to the COM interface, or should I free it inside my function? Thanks!" It's not about whether in C# you need to free an output parameter. It is whether you need to free a parameter in code that implements a COM interface. It happens to include a mention of how the COM interface is being used. – MSN Aug 12 '11 at 20:33
  • Although I suppose if you are being pedantic enough I did omit the conclusion from "the COM interface must not free it" to "C# must free the memory". But I figured that was obvious. – MSN Aug 12 '11 at 20:39
  • 1
    Ok, I was reading it from the point-of-view of the C# developer, "should I free it inside my function" - No, the CLR should do it for you. After reading it again, I believe he is asking whether he should free it from inside his C++ function depending on whether it is called from C# or C++. If that is indeed how he means it, your answer makes perfect sense. – Kyle W Aug 12 '11 at 21:06
0

Do you mean from the point of view of the C# developer or from the C++ developer.

The C# developer should not have to worry about any memory management when dealing with COM+.

Creating a COM+ component in C++, you would not have to know who is calling you, the memory semantics are the same. If it's an in parameter, the caller is responsible for managing the memory, regardless of whether it's C++ or C#. In C#, the CLR takes care of it for them.

Kyle W
  • 3,702
  • 20
  • 32