Managed Code can't have memory leaks, right?

re: Managed Code can't have memory leaks, right?

Ethan Henry — Thu, 20 May 2004 18:46:00 GMT

This is kind of funny to read... I co-wrote an article about this back in, oh, 2000. Though you might have skipped it - it was an article about Java.

http://www.ddj.com/documents/s=888/ddj0002l/0002l.htm

You'll have to register to get at it though.

Anyway, this problem is fairly common in Java apps, especially J2EE apps. There are "memory profiling" tools like JProbe and OptimizeIt that can help track them down. I used to work with the JProbe team (now part of Quest Software).

We called these kinds of problems "loitering objects" to distinguish them from traditional C++ memory leaks where memory can't be freed because the pointer has been lost.

Managed code development is very, very similar to Java development. I highly recommend some of the advanced Java development books to people getting into managed code for the first time. Many concepts are identical.

re: Managed Code can't have memory leaks, right?

BJ Herrington — Thu, 20 May 2004 16:00:00 GMT

Ya, that's what i was refering to with 'COM Release'. I made sure to call it each time I was finished with an ADO object the second time around, but even doing that the GC liked to keep them around for way too long considering the memory the application was consuming. Even on the server I ran the app on (4 gig ram) it crashed well before finishing.

Going for a 3rd try, I called GC.Collect at the end of every proc that used ADO, and even tho it still ate up quite a lot of memory, it did at least finish.

re: Managed Code can't have memory leaks, right?

Larry Osterman — Thu, 20 May 2004 15:55:00 GMT

Absolutely BJ. A very good point.

Btw, you do know about System.InteropServices.Marshal.ReleaseComObject(), right?

re: Managed Code can't have memory leaks, right?

BJ Herrington — Thu, 20 May 2004 14:48:00 GMT

This is especially true when dealing with COM Interop in managed code. I once rewrote some old vb6 code in vb.net using ado. Of course, at the time, I didn't realize that the ado interop was *not* the ado.net lib. Long story short, I created about 50,000 ado objects w/o a single COM Release.

Even later when I rewrote that part, I had to call GC.Collect() very often to keep the app from blowing up to ~800 meg.

re: Managed Code can't have memory leaks, right?

thomas woelfer — Thu, 20 May 2004 08:14:00 GMT

Larry,

thats why i'd really like to see a tool in visual studio that shows the interconnections of allocated objects....

WM_THX
thomas woelfer

re: Managed Code can't have memory leaks, right?

Larry Osterman — Wed, 19 May 2004 22:15:00 GMT

My app was consuming 1.5G of memory before I realized what was wrong. While you're right that it's not TECHNICALLY a memory leak, it might as well have been one.

And some of the subtle bugs I mentioned above can result in situations that are indistinguishable from a memory leak.

re: Managed Code can't have memory leaks, right?

Ryan Gregg — Wed, 19 May 2004 21:47:00 GMT

But this isn't really a memory leak in the traditional sense, it's just a bad piece of code sucking up more memory than you might otherwise think is correct. The memory isn't being lost like a traditional memory leak, and the GC will collect it when everything is disposed, right?

Say, if you dispose the document that all these nodes are being created on. Right? Or am I wrong in thinking that and this really is a leak in the traditional sense?

re: Managed Code can't have memory leaks, right?

Jerry Pisk — Wed, 19 May 2004 21:35:00 GMT

Josh you're right, enumerators don't have to reset on a collection change and XmlNodeList is one of those that don't. Cool :) I actually like features that let you shoot yourself in the foot if you want to.

re: Managed Code can't have memory leaks, right?

dudetron — Wed, 19 May 2004 19:53:00 GMT

we have this problem all the time in GDI+ when creating dynamic System.Drawing.Images at a high rate. calling Dispose() on the image is not sufficient..GC.Collect() has to be called or one encounters tremendous pile-up, again not technically a 'leak' as mentioned above...

re: Managed Code can't have memory leaks, right?

Larry Osterman — Wed, 19 May 2004 19:25:00 GMT

Whoops :) I'll fix that asap.