Reply to: Memory leaks

[VectraMan]

I found out when doing my ed s/w that memory leaks are often bugger all to do with one's own code, rather with Microsofts'. Using any SDI/MFC/.net function calls or objects?, check on the net for problems.

Don't know about .net, but I've never found any genuine leaks with MFC. You can make a leak by creating a GDI object, selecting it into a DC and not unselecting it, but it's debatable as to whether that's a leak or just incorrect usage (you'd reasonably expect a C++ object to sort itself out when it goes out of scope though). Things like BoundsChecker tend to report lots of leaks in MFC that aren't really there, because MFC uses static data that's freed when the MFC DLL is unloaded, and BoundsChecker calculates it's leaks before that happens.

[darmstadt]

GETMAIN followed by FREEMAIN other wise you might well get an S0C4 abend.

[xoggoth]

I found out when doing my ed s/w that memory leaks are often bugger all to do with one's own code, rather with Microsofts'. Using any SDI/MFC/.net function calls or objects?, check on the net for problems.

[VectraMan]

It turns out that most memory is not leaked in the literal sense, but simply hung onto rather than being freed when no longer required.

Told you.

Windows NT/XP releases all resources allocated by a process when that process exits. At least it should release them.

It does, and more importantly also does if the process crashes. So in reality you don't need to worry about leaks at the end of the program, although to not do so is pretty sloppy.

I suspect Unix programmers just feel slightly queazy on a Windows box. NT is quite a good OS, whereas Win3.1 etc were tulipe.

It's true. Windows stills sufers by reputation from 3.1, and 95/98/Me which were all 3.1 underneath, but NT/2K/XP has always been a pretty solid system, and only crappy drivers tend to let it down.

[OrangeHopper]

"... but all NT based windows will free up all memory when the process exits."

Ok, stand corrected. Shows when I last seriously coded on Windows.

[Fungus]

Sorry but I thought ".... but simply hung onto rather than being freed when no longer required ..." was standard windows practice? Everything created on the heap stays unless you explicitly destroy it, even after the program has exited. That is why Unix programmers don't get on too well to start with when asked to write something on a Windows box.

Not sure what you mean. Good programming practice in C/C++ is to free memory when no longer needed regardless of the OS. The client's product allocates huge amounts of memory each second and is supposed to run for days without problems. (Pause while I pick myself up off the floor.) Problem is I now have to figure out why it does not free the memory. Sigh. At least I'm paid well. I've done this sort of tulipe as a permie for half the money.

You should see some of the crap coding in the product. It's what you get when loads of people contribute, with no real sense of ownership, and team members changing regularly. Allocate with new, and de-allocate with free, or allocate with new char[] and deallocate with delete.

Windows NT/XP releases all resources allocated by a process when that process exits. At least it should release them.

I suspect Unix programmers just feel slightly queazy on a Windows box. NT is quite a good OS, whereas Win3.1 etc were tulipe.

[GeorgeGregan]

Everything created on the heap stays unless you explicitly destroy it, even after the program has exited.

That was the case in windows 9x but all NT based windows' will free up all memory when the process exits.

I believe the C runtime uses an algorithm whereby if a small buffer is requested that can't be fulfilled from currently allocated heap memory, it will allocate twice the current level, and it won't go back and free this memory after the buffer is released. This can give the appearance of processes leaking but they will eventually reach an equlibrium.

Or something like that

[OrangeHopper]

Sorry but I thought ".... but simply hung onto rather than being freed when no longer required ..." was standard windows practice? Everything created on the heap stays unless you explicitly destroy it, even after the program has exited. That is why Unix programmers don't get on too well to start with when asked to write something on a Windows box.

[Fungus]

Well I gave in and decided to write some code that would walk the heap just before the application terminated. XP memory allocations are easy to walk as the heap is just a linked list, with useful information in each linked list item.

It turns out that most memory is not leaked in the literal sense, but simply hung onto rather than being freed when no longer required. And a bit of messing about has found where most leaks are allocated.

I would have though that Purify could have done this business for me given that it cost £700 for one fixed seat licence.

[DaveB]

What?

You can keep it up for more than 20 secs??? That's showing off that is.

Not according to his girlfriend

[VectraMan]

Could this be heap based resources that aren't being released? Nothing to do with the code's mallocs.

Try it on Windows 98. If the OS falls over in 20 seconds, it's a resource leak.

[OrangeHopper]

I'm bored again today so I'm going to provide further evidence of my ignorance.

Could this be heap based resources that aren't being released? Nothing to do with the code's mallocs.

Spent ages once tracking down a problem that turned out to be a timer not being released. Under normal circumstance the job did what was expected and the timer was destroyed, however when it it timed out, the old timer wasn't being release while a new one was being created.

Are all the resources being destroyed?

Does your ma like eggs?

[Fungus]

Bounds Checker tends to make everything crawl too, and if you use MFC it reports lots of leaks that aren't really there.

If you stop the program just before it finishes shutting down, does the memory usage go back down? There's a difference between a memory leak (i.e. allocated but the pointer to it is lost so never freed), and a program that incorrectly allocates more and more memory. So if it's all freed at the end then that indicates the latter and should give you a clue.

Hi VectraMan

Yes I've tried to determine if it really is leaking, i.e. losing references, or simply not freeing memory that is no longer used. As far as I can tell it is leaking.

Life is so much easier if it's done right (or nearly right) from the start. Oh well, I s'pose that's why muggins is on the case ...

Thanks.

Fungus

[VectraMan]

Bounds Checker tends to make everything crawl too, and if you use MFC it reports lots of leaks that aren't really there.

If you stop the program just before it finishes shutting down, does the memory usage go back down? There's a difference between a memory leak (i.e. allocated but the pointer to it is lost so never freed), and a program that incorrectly allocates more and more memory. So if it's all freed at the end then that indicates the latter and should give you a clue.

[Fungus]

...oh dear, you're still using a legacy language aren't you?

Joking aside, for this sort of problem in the past I used to find the Numega (or whoever they're owned by, or own, these days) tools very useful. No doubt there are others.

A quick Google should find them or something similar...perhaps even a 30 day trial...my life-saver on many a project.

Thanks, but I've used both Purity and Bounds Checker on past projects. But Purify is not up to the task as it has too high a loading. Sigh.