views:

366

answers:

8

This is either ridiculously simple, or too complex . . . .

In our application there is a form that loads some data from the database and displays it in the grid (putting it simply). When the data is refreshed the total memory usage climbs by about 50K (depending on how much data is displayed no doubt). Sounds like a memory leak, but when we shut down the application, FastMM is set with ReportMemoryLeakOnShutDown := True, and it doesn't report any abnormal memory leaks.

So it appears we have a memory bubble or bag. Something that is accumulating more memory each time it is run. Like a TList that keeps getting new items added to it, but the old ones never get removed. Then in the shutdown process all the items get destroyed. The rows displayed in the grid do not increase, but there are a lot of object lists behind the scenes that make this work, so it could be anywhere.

So my question is if anyone knows of a good trick for finding out what parts of an application are using how much memory . . . . I can think of lots of tedious ways of doing it (which I am in the process of doing - checking each list I can find), so I am hoping someone has a trick or technique I have not thought of.

Thanks in advance!

Update: Every refresh results in an additional 10-50K of memory being used. The users are reporting that eventually the application stops responding. It certainly acts like a memory leak, but FastMM (the memory manager) does not see anything leaking. I'll try some other memory tools . . .

A: 

Does this happen every time you refresh the data or only the first time? If it's only the first time it could be that the system just reserves the memory for your application, despite the fact that it's not used at this time. (Maybe at some point the old and new data existed simultaneously in memory?)

There are many tools which provide you with informations about memory leaks, have you tried a different one?

Georg
A: 

Im not a FastMM expert, but I suppose that after a memory manager get memory, after you free the objects/components, it holds for future use with some zeroes or flag, I dont know, avoiding the need to ask the OS for more memory any time, like a cache.

How about you create the same form/open same data, N times in a row? Will increase 50K each time?

Cesar Romero
A: 

This link seems to have some tools that can help you:

http://delphi.about.com/od/toppicks/tp/aatpmemleak.htm

Bryan Slatner
+6  A: 

Just F8 through the critical part and look at the process usage graph (Process Explorer from Mark Russinovich works great for that). When you find the culprit method, repeat the process but descend into that method.

gabr
+6  A: 

Tools like AQTime can report difference in memory/object usage between snapshots. This might help you find out what keeps growing.

Lars Truijens
A: 

Once I had the same problem. The application was certainly leaking, but I got no report on shutdown. The reason for this was that I had included sharemem in the uses-section of the project.

Have you tried the full FastMM-version? I have found that tweaking its settings gives me a more verbose information of memory usage.

Vegar
+2  A: 

It looks like there is some memory allocated via custom AllocMem() calls, bypassing FastMM.

This can be midas. Andreas has a solution for this

Or some other InitXXX WinAPI call that allocates something, without freeing. Or some other third-party or windows dll used by project.

dmajkic
That may be true, but it might not be. FastMM can only detect "leaks" which are not released at shutdown. It will never detect things which "leak" up until shutdown.
Craig Stuntz
Craig, I'm missing something here. FastMM will detect any allocation and deallocation that are going via delphi mm calls. What do you mean by "things which leak up until shutdown"? Example?
dmajkic
I guess i meant that you can't know it's a leak until you close down the application.
Vegar
dmajkic, consider FDM= TMyDM.Create(Application);. The owner should be the containing class, not Application. So it's a leak , for all of runtime. But FastMM won't report it, because it will be freed on application shutdown.
Craig Stuntz
Then Jim could say to users that it's a feature: "We are cashing some data; we don't know exactly what, but it get released at the end" :-) I meant on "bubble" not referenced anywhere. Yes, could be both.
dmajkic
A: 

As Lars Truijens mentioned, AQTime provides a live memory consumption graph, so in runtime, you can see what objects are using more memory whenever you refresh data.

vcldeveloper