4
votes

Somebody suggested recently ( My program never releases the memory back. Why? ) that my program leaks some memory. I have FastMM set to aggressive and it reports no memory leaks when I shutdown the program.

Anyway, I would like to know if there can be memory leaks that are no detected by FastMM?

Update: I don't personally use Win API to allocate memory. But I am afraid that some 3rd party components I use (not so many) may use it. Can you let me know all possible API calls that FastMM cannot intercept? I will do a search in my code for them. Thanks.


Delphi 7, Win 7 32 bit
FastMM 4.97
I am not interested about interfaces.

6
@Altar I've just written an app that allocates a block of memory, zero fills it, and then deallocates it. The working set statistics, as reported by Process Explorer, go up, and then return to the level at which they started. I'm using a vanilla D2010 with FastMM (which is the default of course).David Heffernan
@Altar My question to you is this. Why do you look for problems with FastMM instead of looking at your own code first? FastMM is incredibly widely used and I would generally be inclined to start from the belief that it does what it does very well.David Heffernan
@Altar Finally, did you try my MSVCRT based MM as posted to one of your other questions? I bet it performs the same as FastMM which perhaps may convince you to stop looking for problems there and look at your own code.David Heffernan
@David I don't think Altar claims FastMM to be the root of the problem. Moreover, it must be something in his code causing the problem, and Altar is looking for a way to find out, what it is.Eugene Mayevski 'Callback
@Eugene Previous questions called out FastMM, it helps to consider this thread in the context of the previous threadsDavid Heffernan

6 Answers

3
votes

No, only memory leaks which memory was alocated by FastMM.

EDIT: Maybe the answer looks wrapped but it is not! If anyone check the FastMM haw is made than can see that every pointer of memory alocation is pushed (and poped out at FreeMem) in to one of stacks (there is more stacks, depend of memory size) so at the end of closing application the FastMM only check stacks, if something in stacks, and if it is, than report memory leak!

4
votes

FastMM is a layer on top of Windows memory management. Obviously, if you (or some component or whatever) uses Windows APIs to allocate memory, then such allocation bypasses FastMM and you won't be able to track it. BTW Delphi memory managers themselves use that APIs to allocate chunks of memory. So if you need to see allocations on that level, FastMM is not enough - you must use tools like AQTime and similar (as I suggested in the previous question).

3
votes

I've never known FastMM to fail to detect a memory leak.

3
votes

There are several possible causes: (which apply to any memory manager)

  • your main program loop leaks memory, but does so to something that is freed on shutdown
    • the simplest case is logging to a memo. The memo gets bigger and bigger, but is destroyed on shutdown.
  • the memory is allocated outside fastmm's control
    • directly allocating from windows
    • memory allocated in dlls etc.
  • Heapfragmentation. A memory manager keeps large blocks allocated (e.g. because it still contains a small % of allocations). Result: The app doesn't use it, but it is not release to the OS either. The runtime/memorymanager keeps it around.
    • fastmm should be more resilient against this phenomena, but in doubt try to print heapmanager info to see if this is the case.
2
votes

There is a lot of good answer already, but one point that wasn't mentionned yet...

There is a lot of "leaks" that won't get detected by most memory leak detector since the memory IS freed, but way after it isn't used anymore. For exemple, object stacked in a TObjectList. Object are put in the object list, but after you are done using them, you don't free them. They will be destroyed when the object list is destroyed too (When application close for exemple, assuming OwnsObject=True). Since the objects are actually freed, objects are not "leaked", but still make your application use more and more memory over time.

FastMM won't report those as it only makes "full run" analysis. To detect those, you need a memory leak detector that allows to do partial runs, that is, analyzing what "leaked" between point A and point B during the execution. AQTime that Eugene mentionned allow that kind of checks. But be aware that is takes a bit of analysis because that will yield many false-positive (Pretty much all "realloc" operations will be marked as a leak).

2
votes

FastMM does not detect leaks of memory allocations not going through FastMM.

This can include GlobalAlloc calls from 3rd party libraries or DLLs you use.
Edit: Microsoft's MSDN has a nice list of memory allocation methods.

This was in fact the problem I mentioned I mentioned in my answer to your previous FastMM question.

You can use a tool like VMMap to track the memory leaks that FastMM cannot detect.

--jeroen