Re: COM interop between C++ and C#
- From: Frederic Forjan <frederic.forjan@xxxxxxxxxxxxxxxx>
- Date: Wed, 11 Nov 2009 21:57:12 +0100
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 :
Frederic Forjan wrote:.[...]
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
- References:
- COM interop between C++ and C#
- From: Frederic Forjan
- Re: COM interop between C++ and C#
- From: Peter Duniho
- COM interop between C++ and C#
- Prev by Date: linq to sql update not working for one column
- Next by Date: C# constructor best practice: how much logic to place in a C# constructor
- Previous by thread: Re: COM interop between C++ and C#
- Next by thread: Re: COM interop between C++ and C#
- Index(es):
Relevant Pages
|