Well at first thanks for looking so persistent into it, and for trying
to establish actual facts rather than just jumping to conclusions.
On 15/08/2011 09:33, Ludo Brands wrote:
I'm noticing also a "slow down" in memory consumption after 5-6
unload/load cycles. I compiled Lazarus with cmem to be sure valgrind
massif recognises correctly the memory manager: results are very
similar. So the probability that memory isn't returned by the program
(vs memory manager) is growing. So far I have been concentrating on
the memory usage before and after closing the 450 files. I'm now
concentrating more on what increases when unload/load the 450 files
since that would really be the "bad" memory. Interesting finding so
far: - the gutter images don't increase, nor do the codecaches
mentioned before.
The gutterimages should be freed. otherwise they would have to show as
leak at the exit. or they are a leak in the widgetset, in which case
heaptrc may not notice.
Try a small app with just an image list. add images, then destroy the
image list. And see if qt leaks.
"codebuffer" if this is a name from the debug symbols, then thta is
probably codetools. SynEdit uses a different name
They stay in memory but apparently are reused. - a big memory chunk
that grows is memory allocated by pthread_create called from
Qthread::start. The stack trace mentions QFileSystemWatcher::addPath,
IBusPlugin. I mention QFileSystemWatcher and IBusPlugin because after
a lot of testing, Lazarus failed to start with an error
QInotifyFileSystemWatcherEngine::addPaths: ,inotify_add_watch failed.
I had to reboot the system.
Don't know about any of this. sounds like something is watching for file
changes??? codetool does. But last time I checked, it didn't use any OS
notification, but rather by just getting the file's modified timestamp
itself.
So I wonder why QT foes that.
Also that may be qt specific. But the memory growth happens on other
widgetsets too. And While possible, it would be strange, if it was
leaking on qt, but mem management on other OS?
I also don't know where the threads are coming from. I do not know if
Lazarus does create any of them intentionally (maybe something that was
added lately?). I know on w32 for example that the ODS sometimes creates
them (e.g for fileopen dialog)
The threads created are all shortlived (I can't find a lot of threads
attached to Lazarus). I read somewhere that pthread releases resources
when pthread_detach or pthread_join is called, not after a
pthread_exit. This could explain resources held back for threads not
running anymore, and nicely released when the program finishes. This
is probably Qt specific. But, the same stack trace also shows that
CUSTOMFORM_SETWINDOWFOCUS causes 1/3 of the Qthread::start. I'm
surprised that loading multiple files in an editor should move focus
to every window. Another 1/3 is triggered by TMENU_ITEMCLICK
triggering much later a QFileDialog_create. Is that how files are
loaded? I'll look further into this.
Strange. I wouldn't expect a fileopen dialog.
Maybe if a fileopen-dialog-component is used in an app (as it is in
Lazarus) then some initialization happens on application start, rather
than on execute?
Try putting a fileopen dialog on the form of an empty project....
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
