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

[Martin]

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....