Question

I have the following situation:

I am using a third party .net library which calls into unmanaged code to do what it needs (the .net stuff is just a thin wrapper). That library has various IDisposable implementations etc which I am wrapping in usings but it still leaks memory like an, err, sieve I suppose (I have been able to prove this conclusively in a unit test).

Ideally of course I would get the third party to fix their library but they are not responsive and I, sadly, cannot drop it either so what I am currently doing is this…

The work I am doing with this third party library can be pretty easily encapsulated so where I need it I launch a process with a couple of command line arguments and capture the standard out. That process does what it needs to do and returns a result object by simply serialising it to the standard out whereupon the method in the launching application which kicked off the process deserializes the result object and returns it just as if nothing freaky has happened.

Obviously this is all pretty icky (command line argument parsing, serialising etc all adding complexity and slowing things down) but it has the advantage that it is pretty simple and it works (thankfully you can even turn off the window with CreateNoWindow so the user of the application doesn’t notice anything untoward either).

Other approaches I thought about:

• Unloading app pools and whatnot but since the memory that is leaked is allocated outside of .net I figure that probably wouldn’t help or would it?
• I also looked at trying to unload the DLL but it looks kind of fraught with danger – can I do this safely and reliably?

So, my question basically boils down to…

Is there a way that I could keep everything in process and somehow clean the bottom of this third party library for it so I do not leak memory?

Answer 1

…it still leaks memory like an, err, sieve I suppose (I have been able to prove this conclusively in a unit test).

I’m assuming the answer is ‘no’, but I have to ask — is there any chance it “leaks” memory
during normal use, but is smart enough to clean it all up when you “shut it down”? I’ve encountered at least a few libraries whose internal caches seem to grow in an unbounded manner, but which get cleaned up when the library’s termination routine is invoked.

Assuming the leaks are really just bugs, then…

…where I need it I launch a process with a couple of command line arguments and capture the standard out

…I think your approach here is the most reasonable one, given the parameters of the situation. In effect, you’re hosting code that you don’t “trust” — perhaps not for security reasons, but for performance / reliability reasons.

Unloading app pools and whatnot but since the memory that is leaked is allocated outside of .net I figure that probably wouldn’t help or would it?

Correct — that won’t help.

I also looked at trying to unload the DLL but it looks kind of fraught with danger – can I do this safely and reliably?

That most likely won’t solve the problem. If the code is as buggy as you say, it’s most likely not going to be good about cleaning up its allocated resources when it gets unloaded. (And the system isn’t going to clean up its resources for it either–if it allocated a resource without freeing it, that resource will effectively leak.)

There’s really not much you can do otherwise in this case. The only last-resort option I can think of is trying to hook / intercept the 3rd-party library’s routines, somehow forcing all of its allocations into a pool that you can free all at once (after freeing the library). But you really shouldn’t try doing that. It’s quite dangerous, almost certainly not worth the effort, too hard to implement correctly, etc.