Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!
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.
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.
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.
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.
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.
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.
Comment