COM interop between C++ and C#

[Frederic Forjan]

Hello all,

We have a probleme about COM interop between native C++ and C-Sharp.

OUR application is develop with ATL/C++ and MFC 6.0

We are trying to integrate a third-party component, develop in C# based
on .NET 1.1.

The interop is done thru COM since the interface/contract us was design
to be COM. The provider of this component choose to develop it in C#.

Our applicqtion is like a client/server with this third-party component
- interfaces, callback, notification..
The contract was in fact design in C#, but generate the COM interop DLL
and we are implementing some part like the UI part on our side in C++.

The COM interface are mainly dealing with SAFEARRAY of XMLDocument and
BSTR, but on the .NET side they are using lot of StringBuild and Xml.

But we have detected lot of memory leaks from our side.

Since this component is also use in .NET application and seems there is
at this stage no problem detected on it.

Questions
Do you know if there is some problem in .NET interop wrapper (memory
leaks, some parameters to use..)

Do you have any design pattern to use for us on ATL side or on .NET side
for the garbage collection ?

Do you have any idea for tools or usage to detect where the memory leaks
comes ?

Regards,
Frédéric Forjan

 

[Peter Duniho]

[...]
But we have detected lot of memory leaks from our side.

What does that mean? How did you "detect a lot of memory leaks"?
Memory leak detection is notoriously ineffective at preventing false
positives. There are tools that help a little, but ultimately, short of
manually inspecting 100% of your data structures and proving that some
block of memory that is still allocated isn't referenced anywhere in
your program, it can be hard to know for sure you actually _have_ a
memory leak.

Since this component is also use in .NET application and seems there is
at this stage no problem detected on it.

Questions
Do you know if there is some problem in .NET interop wrapper (memory
leaks, some parameters to use..)

None that I'm aware of per se, though granted it's not an area of .NET
I'm very familiar with. The more usual problem is handing a managed
pointer to unmanaged code without properly guarding it from garbage
collection (and obviously that's a client code issue, not .NET problem).

Do you have any design pattern to use for us on ATL side or on .NET side
for the garbage collection ?

Not sure what that means. On the .NET side, GC is automatic. That's
the point of GC. On the ATL side (which, IIRC doesn't have a GC memory
manager), without GC there's no need for a design pattern to use for GC.

Do you have any idea for tools or usage to detect where the memory leaks
comes ?

Google turns up a large number of hits with the search terms "memory
leak detection". Adding "automatic" to that turns up some overlap, but
also some additional information. (Oddly enough, the program that was
widely used a decade ago doesn't seem to appear in the search
results…unfortunately, I don't actually recall the exact name…I supposed
it's possible the program was renamed, or just is no longer
produced/maintained).

Note that all tools will be limited to some extent. For non-GC memory
management, they will all rely on being able to inspect your process's
memory and look for references to allocated blocks. There's a variety
of ways this can go wrong.

One of the most effective approaches I've used is for the application
itself to have some diagnostic code that runs at idle time. For every
data structure used in the program, you add DEBUG-only code that
"registers" any allocations known to that data structure. Then these
are compared to the known allocations (you also have to override the
memory management API, of course, for easiest implementation).
Mismatches are reported as errors.

This latter approach has the advantage that with effort, you can ensure
that _every_ reference in your code base is covered. You can also add
diagnostic code to the memory management override to save stack trace
information, which can be helpful figuring out where a block of memory
was allocated. The downside is that it can be labor intensive, as every
single new feature of the code winds up having to include support for
the memory tracking stuff.

It seems like a royal pain when you're implementing it, especially if
you have to retro-fit the code. But when you have an actual leak, it's
surprising how worthwhile all the trouble turns out to be.

On the .NET side of things, Red Gate has a memory profiler that can be
used to help track down the GC equivalent of a memory leak:
"pack-ratting", or in other words, the unintended retention of a
reference to some object.

Dealing with memory leaks is complicated enough when you have all the
information related to the question. At the moment, I don't feel I do.

Pete

 

[Peter Duniho]

[...]
Do you have any idea for tools or usage to detect where the memory leaks
comes ?

Looks like something similar to what I described as an internal
diagnostic tool exists in Visual Studio now (and has for awhile):
http://msdn.microsoft.com/en-us/library/x98tx3cf.aspx

 

[Jie Wang [MSFT]]

Hi Frederic,

I think Pete got to the points very well.

Besides, in case you don't know, the managed support service of the
newsgroup CSharp is now available instead on the MSDN Forums. You can post
the questions in the forum with the Windows Live ID used to access your
Subscription benefits. Our engineers will assist you in the new platform.
The article http://msdn.microsoft.com/en-us/subscriptions/aa974230.aspx
introduces more information about the migration.

For .NET/COM interop questions, you can post them on the Common Language
Runtime forum: http://social.msdn.microsoft.com/Forums/en-US/clr/threads

If you have any questions or concerns, please feel free to contact us:
(e-mail address removed).

Regards,
Jie Wang

Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 2 business days is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions. Issues of this
nature are best handled working with a dedicated Microsoft Support Engineer
by contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Frederic Forjan]

Thanks for those link and this explanation,
Seems a good starting point, also for the C# side since we don't have
lot of debugging skills in C# - yes still working with C++

Frédéric Forjan


thiPeter Duniho a écrit :

[...]
But we have detected lot of memory leaks from our side.

What does that mean? How did you "detect a lot of memory leaks"? Memory
leak detection is notoriously ineffective at preventing false
positives. There are tools that help a little, but ultimately, short of
manually inspecting 100% of your data structures and proving that some
block of memory that is still allocated isn't referenced anywhere in
your program, it can be hard to know for sure you actually _have_ a
memory leak.

Since this component is also use in .NET application and seems there
is at this stage no problem detected on it.

Questions
Do you know if there is some problem in .NET interop wrapper (memory
leaks, some parameters to use..)

None that I'm aware of per se, though granted it's not an area of .NET
I'm very familiar with. The more usual problem is handing a managed
pointer to unmanaged code without properly guarding it from garbage
collection (and obviously that's a client code issue, not .NET problem).

Do you have any design pattern to use for us on ATL side or on .NET
side for the garbage collection ?

Not sure what that means. On the .NET side, GC is automatic. That's
the point of GC. On the ATL side (which, IIRC doesn't have a GC memory
manager), without GC there's no need for a design pattern to use for GC.

Do you have any idea for tools or usage to detect where the memory
leaks comes ?

Google turns up a large number of hits with the search terms "memory
leak detection". Adding "automatic" to that turns up some overlap, but
also some additional information. (Oddly enough, the program that was
widely used a decade ago doesn't seem to appear in the search
results…unfortunately, I don't actually recall the exact name…I supposed
it's possible the program was renamed, or just is no longer
produced/maintained).

Note that all tools will be limited to some extent. For non-GC memory
management, they will all rely on being able to inspect your process's
memory and look for references to allocated blocks. There's a variety
of ways this can go wrong.

One of the most effective approaches I've used is for the application
itself to have some diagnostic code that runs at idle time. For every
data structure used in the program, you add DEBUG-only code that
"registers" any allocations known to that data structure. Then these
are compared to the known allocations (you also have to override the
memory management API, of course, for easiest implementation).
Mismatches are reported as errors.

This latter approach has the advantage that with effort, you can ensure
that _every_ reference in your code base is covered. You can also add
diagnostic code to the memory management override to save stack trace
information, which can be helpful figuring out where a block of memory
was allocated. The downside is that it can be labor intensive, as every
single new feature of the code winds up having to include support for
the memory tracking stuff.

It seems like a royal pain when you're implementing it, especially if
you have to retro-fit the code. But when you have an actual leak, it's
surprising how worthwhile all the trouble turns out to be.

On the .NET side of things, Red Gate has a memory profiler that can be
used to help track down the GC equivalent of a memory leak:
"pack-ratting", or in other words, the unintended retention of a
reference to some object.

Dealing with memory leaks is complicated enough when you have all the
information related to the question. At the moment, I don't feel I do.

Pete

 

[Peter Duniho]

[...] (Oddly enough, the program that was
widely used a decade ago doesn't seem to appear in the search
results…unfortunately, I don't actually recall the exact name…I supposed
it's possible the program was renamed, or just is no longer
produced/maintained).

Okay, it finally came to me:
http://en.wikipedia.org/wiki/BoundsChecker

There are lots of competitors now, but it used to be that was the one.
At the time, false positives were a huge problem. Maybe they (and their
competitors) have gotten better...I haven't bothered to check it out,
but it could be worth a look.

If one has an actual memory leak issue, that is. The OP wasn't really
clear on that question, and no follow-up has been made to elaborate.

Pete