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...
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
