Memory management cause of COM server crash

I finally got to the source of the problem I was having about a month
ago that was causing Dolphin to crash when used as a COM server. (See
news:3C75C17A.EA2C7D69%40shoshana.com) Thought that I'd document it here
for everyone's benefit.

The problem came down to a string parameter that's coming out of Dolphin
though the COM interface. It's declared in the IDL as:
    [out] BSTR* outString
My implementation in a subclass of AXDualImp had been:
    outString value: returnString asBSTR.
which works most of the time ;-)

Crashes would occur more or less frequently depending on how many calls
were made to the server, how big the memory footprint grew, the phase of
the moon, which way the wind was blowing...

Since it was hard enough to reproduce, I managed to ignore it for some
time. But after stripping and deploying an executable, it was crashing
much more easily. (I guess if one's mangling memory, after removing all
the unused bits, it's much easier to hit something vital). It was still
hard to isolate. But by running some tests using the Dolphin image as
the client rather than VisualBasic, I found that the crashes were
occurring much closer to the source of the problem, and was finally able
to zero in on it.

The implementation should be:
    outString value: returnString asBSTR detach.

Without the "detach", the memory used by the string apparently gets
freed twice. This can lead to nasty consequences.

Is there someplace in the documentation that discusses memory management
issues such as these between Dolphin and COM? I did a search of the
Object Arts site for "detach" and didn't find anything.

-------------------------------------------
Bill Dargel            [hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA

Bill,

> The implementation should be:
>     outString value: returnString asBSTR detach.
>
> Without the "detach", the memory used by the string apparently gets
> freed twice. This can lead to nasty consequences.

Here are some of Blair's words (hopefully not taken too much out of context)
that I found in a 5-22-98 post of mine: "Basically, however the parameter
attributes are defined, then the caller is responsible for freeing the
memory. In the case of in and in-out parms, the caller also allocates it.
In the case of out parms the callee allocates the memory. In the case of
in-out parms the callee may reallocate the memory if necessary, but apart
from that the callee never frees memory."

In your situation, #asBSTR creates a BSTR that by default will free itself
on finalization; #detach removes the BSTR's sense of responsibility for the
memory, leaving it up to the caller to free it.


> Is there someplace in the documentation that discusses memory management
> issues such as these between Dolphin and COM? I did a search of the
> Object Arts site for "detach" and didn't find anything.

Ian's newsgroup archive is often the best place to look.  COMTaskMemory is a
good keyword to find posts relevant to memory management rules.

The following from the wiki might be helpuf:
  http://www.object-arts.com/wiki/html/Dolphin/ExternalInterfacing.htm
  http://www.object-arts.com/wiki/html/Dolphin/COM.htm

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]