how to track down a growing memory use that is not a memory leak
(solved)
lazarus / 34-Windows

----------------------------------------------------------------------
mas steindorff · 2019-06-06 22:14

I have an app that uses TCollection, TCollectionitem, and Tstringlist
heavily.  when i run the app, I can see it's memory use increase with
the windows "resource monitor" and the program slows down.  the
strange thing is I only really allocate memory on startup where the
TCollection is populated and each TCollectionitem's 3 tstringlist are
created.  otherwise there are a lot of local create and free operation
local to the main code at the procedure level.
I have no memory leaks reported by the Heaptrc debug option but it
does see the large memory use. (both 32 & 64 bit)

I'm thinking it's may be due to me sorting my Tcollectionitems which I
do a lot of. I'm thinking I will need to bracket my code with some
sort of call to getfpcheapstatus() or simuler.

Does anyone have any other (simpler) suggestions on how to track this
bug down?

----------------------------------------------------------------------
lucamar · 2019-06-07 01:42

Do you add lines to the string lists over time? That may be one
reason.

Simply sorting the colection shouldn't cause more than a temporal
increase unless some object isn't getting destroyed when it should--
but then you'd have a memory leak somewhere.

----------------------------------------------------------------------
mas steindorff · 2019-06-07 02:00

Quote from: lucamar on June 07, 2019, 03:42:03 amDo you add lines to
the string lists over time? That may be one reason.
no, they are modified, but always have less than 10 strings each.  I
do use tstr[n] :='new string'; where I need to change the the value of
an exciting string.  I can imagine that would trigger a new memory
allocation but all of my strings are short (first names of members).

I have 3 different ways of sorting the Tcollection and do so 10,000++
times a run.  I'm letting the Tcollection sort itself by using it's
.sort(@sortfunction) and simply point to a different function each
time.
I see this program slow down issue when I run continuously for a few
seconds. I can see a small increase in memory usage for each run so I
,at least, have a path to debug.

----------------------------------------------------------------------
lucamar · 2019-06-07 04:55

Perhaps you should try to track each allocation/deallocation of
collection items and make sure there is no code in the sorting
routines duplicating items.

Other than that I can't say. It's difficult to guess what can be wrong
(if anything) without seing some code.

----------------------------------------------------------------------
mas steindorff · 2019-06-07 22:46

thanks for the offer to help but I was more after a debugging approach
rather than a solution.
I went with the GetFPCHeapStatus debug approach and found the issue. 
All of the pascal objects worked just like they should including ...

 my debug memo I had on another form 
(it was growing larger with debug printouts from each new run)

----------------------------------------------------------------------
lucamar · 2019-06-08 00:56

Happens to the best; one sees the forest and misses the individual
trees.