[Lazarus] RE : RE : RE : Console App Development

[Martin]

On 14/08/2011 12:20, Ludo Brands wrote:
> Valgrind massif looks at the heap and can't distinguish memory 
> released but kept by the memory manager or memory not released. For 
> massif it is allocated by the program under test and reports where it 
> was allocated. 
So we can't be sure about whta memory is actually kept by the IDE


>>> They clearly show that a lot of data is staying in memory. It'll

Sorry, but how does that go with the above statement?
Well yes technically the data is still in memory. In memory that the 
heap manager still keeps, but that to the application has been freed.


>>> One I found out is that synedit creates an image list with gutter
>>> symbols for every page!
...
>>> That adds up to 3 M for the 450 file, which apparenltly aren't
>>> released when
>> Hm, strange, not sure which one you refer too.
>> BookmarOptions has an image list (the digits for bookmarks), but the
>> image list is actually a single instance  created by
>> SourceEditorMarks)
>>
> Here is a chunck of the valgrind output I spent some time on and which I'm
> referring to (this is lazarus Qt):
....
> | |   |     |             |   ->01.09% (3,145,728B) 0x868A582:
> SYNGUTTERCODEFOLDING_TSYNGUTTERCODEFOLDING_$_INITPOPUPIMAGELIST_NEWIMG
> (synguttercodefolding.pp:193)
> | |   |     |             |     ->01.09% (3,145,728B) 0x868A394:
> SYNGUTTERCODEFOLDING_TSYNGUTTERCODEFOLDING_$__INITPOPUPIMAGELIST
> (synguttercodefolding.pp:201)

Those are images created for the gutter pop up menu. And There are calls 
to free the image list when synedit is destroyed.
If QT keeps something in memory, then maybe it's a problem in the QT 
parts, or qt itself.


About it created per synedit instance. This may not make sense in the 
IDE, where the images are indeed equal.
But SynEdit can be used in other apps.  I don't know if an interface 
exists, but it well could in future, that would allow individual 
synedits to use different images.
Sure even then it can be solved, and a singleton default image list 
could be created...

at the moment it isn't exposed. so if anyone supplies a well written 
patch...

to me it's not worth the work, as it only applies to artificially 
created extreme situations. In normal life it does not cause a real 
problem. => doesn't mean it wouldn't be done, just that it currently is 
very very very low in priority

>> Whil the lack of freeing memory may in parts be caused by
>> Lazarus,  (do
>> not know), it is not entirely caused by Lazarus.
>> There is definetely some memory freed.   And this freed mem
>> is not going
>> back to the OS for a reason outside the control of Lazarus.
>>
> Yes, but not 30M.
I haven't counted the lines in the 450 files. but say we half my 
estimate 400,000 lines => I guess they will easily be in there.

Each line is a string. Even if the data of the string had a ref-count > 
1 (which I am 99.999% sure it has not) alone the "array of string" (the 
list of pointers) would be 1.6 MB (probably much more, as it is more 
lines). Add to that other "per line data" that synedit must keep (I know 
of at least 6 other bytes per line, maybe more) already 3 MB or more.

I have not even those seen returned to the OS => and I have single 
stepped (debug) through the code that frees the memory. So clearly 
memory freed by the IDE, is hold in some pool somewhere else.
You can start debugging the various memory managers for that, if you wish.

Now once it is known that this does happen, the same may happen for any 
other of the "unfreed" memory. It may or may not. It is totally unknown.
Of all the unfreed memory, when you close the editors, or project 
anything from 0.1% to 99.9% could be hold by the memory manager.

>> I do not know, if valgrind would detect such mem as freed or not.
>>
> No, it won't.
>
> If interested, I can forward you the full massif and ms_print output.
>

Sorry wouldn't currently be able to look at it...