Thanks for all the information

there isn't a single control. evas has various caches, edje has, there are mempools and those are set up by code, and so on etc. etc. - so you'd have to tweak various things to force free and some cant be force freed at all without modifying the code to no longer use a pool etc.

I think it is make sense to reuse memory, instead of realloc

you'd have to stress it and re-use a lot of objects to see if there is a leak. we do have memory pools and trash etc. like @bu5hm4n says - we alloc and keep around that memory then re-use it again. you'd have to do a lot of allocs over and over and then see the mem footprint keep going up and up and never stabilizing. i adapted your code a bit to do this with a timer ever 0.01 sec:

I think this is some internal object reusing mechanism, isn't there some code in efl_object that takes pointers from the trasher ? I guess simular things are in Evas, this will add up to something like the mem increasing that you see

Thank you Peter! Enlightenment really rox! Just as my beloved FreeBSD! This is something really really new and the design is simply amazing.. really reminds me of the old good Unix or even Amiga times! :-)

cederom, you should begin with full uninstall E and EFL, port version of EFL is really outdated. Then you should download the last versions from enlightenment.org (or checkout from Enlightenment git) and build both EFL and E from sources.
I'm on git versions (dated some months ago) on FreeBSD 11.2. It's stable, I'm using it every day ~12hrs by day without freezes. I tested everything on FreeBSD 12 too without problems.
I did not (yet) tested the last released version of EFL.
You can ask for help in maillist if you have problems with build.

How can I track down the problem?

because the canvas didn't go through a render cycle - nothing changed visually thus it didn't render. it has to actually go through a full cycle. try show some of those rects and leave them there for 1 frame.... then delete them.

@raster Thank you for clear it out.

because evas object deletions are DEFERRED. they require render cycles to drive the deletion. they will be kept around for 2 render cycles so evas can do a prev state vs current state check., imagine u delete a visible object - how can evas know what changes - what area is occupied that now needs re-rendering? was it visible or not, was it set to a color of 0 0 0 0 which EFFECTIVELY made it invisible to rendering even if it was shown... thus objects invisibly have extra references to them that are removed if delete flags are set by the render cycles, so the above case is just "invalid" in that any real process will never do the above and will have a fairly limited upper bound on how many objects will be created then deleted before a render cycle happens. if there really is a very big spate of creating invisible objects (e.g. you're using evas as an image processing engine where you might load an image file into an image object then save it out as another format) then there is evas_norender(evas); which does a render cycle without doing the actual rendering thus driving the object deletion pump. it's an incredibly rare day this is ever needed and if it is used, any updates from objects that really did need a render will be lost. you would need to manually add a damaged region for the whole canvas output to force a full re-render to avoid this if this ever were the case.

@raster Can you please take look at this?

I haven't seen this issue for over a month, so I assume it was transitory. Closing 'Resolved' ...

I'm seeing behaviour that might be related. I'm working on a gtk3 app that renders some gtk3 menus in a menubar. When running under Wayland, the 1st time that an application window renders a menu, it appears slightly offscreen ( slightly too high ). If I close the menu and reopen it, nothing appears ( the parent menubar widget becomes highlighted, but no menu appears onscreen ). These menus, which are dynamically generated and appear in all windows, have the same issue in every window ... and we always see the same pattern of the 1st menu per window being slightly offscreen, and others completely invisible/offscreen.

This is a too old patch, nobody keeps tracking on this anymore.

I can confirm this behavior is still present, which makes the desktop client pretty useless for nested conversations and messages resend.

Fixed issue of e_drm2.x not properly linking for 1.22.0 added functions

Same issue with X environnement

Fix comilation failures

Added this commit to Moksha in my branch ylee. Will be merged into master for our next release. Only commenting this info since ProhtMeyhet mentions it above,

Correction of value overflow (proposed by pascal@ordissimo.com).