Does FastMM detect all memory leaks

Question

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.

Hungerford

@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). – Recorder

@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. – Recorder

@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. – Recorder

@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. – Kelikeligot

@Eugene Previous questions called out FastMM, it helps to consider this thread in the context of the previous threads – Recorder

@David Exactly, David, exactly. – Kelikeligot

@David. The original question is 'Does FastMM detect ALL leaks'? If yes, why the program does not return to original size after releasing the memory, as in your experiment? – Hungerford

@David "and then return to the level at which they started" - - - So you are saying that in YOUR case, FastMM is not caching the memory? It is releasing the memory instantly? Odd. – Hungerford

@Altar Yes, I see the working set return to 8MB which is the value when the program starts. As I have said, I don't believe there is a problem with FastMM and you need to start looking at what your code is doing. Did you try with my MSVCRT based MM? That should show that another MM behaves the same way. You just need to place that unit first in the uses clause of your dpr file. – Recorder

Why dont merge all 3 questions in the one, just to avoid "previous question" reference and confirmations for already said statements? – Halibut

@user205376 merge would be a mess cause that are different questions which can be treated independently. Also cross-referencing related questions is a common practice on StackOverflow. – Kelikeligot

Answer 1

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!

Curtsy

No. It isn't wrapped. I checked the code (including 3rd party code) for API calls that are allocating RAM and found it free of them. – Hungerford

Answer 2

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

Recorder

Would be interested to hear an explanation for the down vote. Perhaps someone here has experience of FastMM failing to detect a memory leak and it would be great to share that experience with us all. – Recorder

I didn't downvote, but I do have a bad experience with the other FastMM myth. For my main codebase, it was much slower than the original MM. – Tiber

@Marco I've got no problem with downvotes, it's just that without an explanation then nobody can learn. What I like about SO is that I get to learn. As for FastMM performance I've only found it a problem under heavy thread contention, that's why I use malloc from MSVCRT. The old Borland MM failed catastrophically for addresses >2GB which was a show stopper for me. – Recorder

@DavidHeffernan David I remember seeing one of your replies on StackOverflow were you posted code showing a very simple bare bones MemoryManager you use. I can't find that post. Do you remember what answer that was? Thanks a lot!!! Sorry to contact you this way. :-) – Jowett

@santiago https://mcmap.net/q/473854/-need-multi-threading-memory-manager these days I now use a different mm in my apps that is designed to work well with NUMA – Recorder

@santiago one of my own making that is tailored for my apps behaviour. It stands on top of HeapAlloc Win32 API and uses one heap per thread. Or perhaps one heap per NUMA node, I can't remember right now. – Recorder

Answer 3

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).

Insnare

Hi Eugene. Thanks for your confirmation. No. I don't use Window API to allocate memory. – Hungerford

@Altar You don't but maybe some component does. – Kelikeligot

You are right. I was going to do a search for this kind of API calls in the 3rd party code I use. – Hungerford

Answer 4

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.

Tiber

Answer 5

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

Niue

I am going to search for malloc and GlobalAlloc now! Anybody knows any other similar calls that I should look for? – Hungerford

I have found only two libraries that are using GlobalAlloc: Melander Gif, Melander DragAndDrop. I don't use them in this project of mine . So, FastMM should be able to detect all memory leaks. – Hungerford

@Altar: almost any non-Delphi COM object and C DLL will use non-FastMM memory allocations. – Niue

Thanks a lot for that list Jeroen. Until now I have checked the code for malloc and GlobalAlloc. - - - "almost any non-Delphi COM object and C DLL will use non-FastMM memory allocations" I know, but I don't personally use COM, neither external C DLLs. – Hungerford

Answer 6

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).

Photofluorography

Actually I have objects stored in a TObjectList and I do understand your point but it DOESN'T APPLY to my case. The objects that I use are linked to the MDI child forms that I create (hundreds of them). The MDI child is creating those objects. When I free the MDI forms they free all objects. But otherwise, your example is very solid. – Hungerford

Ken, that's not a memory leak in any real sense - you still have a reference to each object. It's just poor programming to hang onto things if you don't need them any more. – Decadence

Hence the quotes around "Leaks". Those are not real leaks, but they have the exact same consequences/symptoms as real leaks. They are also often overlooked as they are harder to find. And it's not necessarily a consequence of bad programming, in many situation, nothing short of a full reference counting implemention can ensure an object won't outlive its usefulness. Sometimes, such an implementation is prohibited (as the system architect isn't always the smartest/most knowledgeable person. I've been prohibited from using delegates(i.e. Events) on systems in the not so distant past) – Photofluorography