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

[Ludo Brands]

> 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.
> 
In a previous message I already mentioned that I wrote a small test app
exactly doing that: all memory was returned to the OS. Of course the memory
wouldn't be scattered as it would be in lazarus.
The fact that the memory used by gutter images doesn't grow after
unload/load cycles does indicate that "somebody" holds on to it but reuses
it. Remember I use cmem now, so it probably isn't the memory manager.
Like I wrote earlier, for the time being I'm focussing on what memory usage
grows in these cycles.

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

Because the massif tool takes some time to run and even more for me to
interprete, I started doing the same on a different machine for gtk. Memory
growth is smaller, 20M on amd64. Interesting here is that memory growth is
located in 2 areas:
- pthread_create, again, invoked from gtk this time with no lazarus code in
the stack trace. Stack trace starts with a g_closure_invoke whih indicates
an event. Will be difficult to locate the source.
- again the TMENU_ITEMCLICK, similar location as for qt, found on the
stacktrace. This time not losing memory in pthread but in codetoolmanager...

Looks like the memory loss is different for the different widgetsets.  

> 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....
> 
One of the problems when interpreting massif data is that they are
cumulative. In this case one file open dialog ( the one I used to open the
450 files) triggers 450 DOOPENFILEEDITOR calls. I wrongly interpreted this
as many file open dialogs... 

Ludo