views:

189

answers:

3

I've got the situation where the cycle of loading and then closing a document eats up a few Mb of RAM. This memory isn't being leaked as something owns it and cleans it up when the app exits (Visual Leak Detector and the Mac Leaks tool show agreement on this). However, I'd like to find out where it's going. I'm assuming it's some sort of cache in the application that gets populated when the document loads but not freed when the document is closed. Which methods or tools could I use to find out where these allocations are being made?

UPDATE:

Following Hans's post I added a loop to the app to repeatedly open and close documents. I found that there was an initial jump in memory usage ('Private Bytes' as reported by Process Explorer) after loading the first couple of documents, but then it no longer increased every time. So this suggests that there are no new allocations, and the apparent increase is likely to be mostly due to an artefact of paging.

I've also taken a closer look at Instruments on the mac, which was useful for seeing where allocations were happening: create an Instrument composed of the Allocations and Leaks tools then add a heap snapshot at the start and end of a cycle and in the Heapshots list it'll show all the allocation deltas relative to the last snapshot. This suggests that on the Mac the memory allocations were increasing but it was due to internal caches such as CoreGraphics drawing, over which we have little control.

+2  A: 

Well, actually you have a leak. When the application exits the OS cleans up all the resources: no application leaks in the sense that leaves memory permanently allocated after it quits. XCode has a tool to help you to identify leaks.
Look under

Run->Run with performance Tool->Leaks
That will run your application instrumented with code that will help you find the leaks.

garph0
I forgot: it will give you a visual tool, too, to observe what is been leaked and the call stack that lead to the leak.
garph0
I mentioned that I've already run Leaks and it hasn't found a problem. The memory is most likely allocated by a cache inside the application, and that cache is being freed correctly on the application exit. My question is how do I find which particular cache is accounting for all the memory so that I can flush it when I close a document?
the_mandrill
My bad: I did not realize that you meant the Xcode Leaks performance tool. Was it Visual Leak detector or Mac Leaks?
garph0
+4  A: 

If you can reliably reproduce this you should be able to use the debug heap in the MS CRT to troubleshoot this. Start here: Memory Leak Detection and Isolation

Evgeny
I may try that -- I haven't tried using the MS CRT routines for a few years as it used to be the case that they didn't build with our codebase. I think it was something like the use of 'placement new' that it didn't like.
the_mandrill
+1  A: 

Working from the assumption that it is actually RAM you've measured: sure this is entirely normal. Your program is actively addressing virtual memory pages when loading a document, they'll get mapped to RAM. They'll stay there until another process needs to have pages mapped to RAM. Some operating systems trim the working set pre-emptively, on Windows for example when the app's windows are minimized.

If it is actually virtual memory pages you've measured: that's normal too. After you release the memory, the heap blocks are added to the list of free blocks, ready to be used by the next memory allocation. If releasing the memory happens to free an entire range of pages then the memory manager has an opportunity to unmap that range. It doesn't happen often and its an implementation detail of your memory manager how aggressively it does so.

Hans Passant
Useful comments -- I hadn't considered that. Perhaps I need to run a test case where the app will repeatedly open and close files to see whether it really is allocating more memory or whether it's just a quirk of the paging. The value I'm measuring is 'Private Bytes' as reported by Process Explorer.
the_mandrill
That's virtual memory, not RAM. It includes free blocks in the heap.
Hans Passant