On Tue, 3 Dec 2019 19:52:10 +0800 (CST) Jing  <chenjing...@126.com> said:

Output from smem every few seconds (about every 5 seconds or so per line).
The numbers at the end of the line are USS, PSS, RSS:

$ while [ 1 ]; do smem | grep edje-anchors; done
12153 raster   ./edje-anchors                     0     3576     5619    22988
12153 raster   ./edje-anchors                     0     3576     5619    22988
12153 raster   ./edje-anchors                     0     3660     6038    23764
12153 raster   ./edje-anchors                     0     3788     6104    23768
12153 raster   ./edje-anchors                     0     3664     6042    23768
12153 raster   ./edje-anchors                     0     3664     6042    23768
12153 raster   ./edje-anchors                     0     3920     6169    23768
12153 raster   ./edje-anchors                     0     4292     6670    24396
12153 raster   ./edje-anchors                     0     3668     6046    23772
12153 raster   ./edje-anchors                     0     3668     6046    23772
12153 raster   ./edje-anchors                     0     3668     6046    23772
12153 raster   ./edje-anchors                     0     3672     6050    23776
12153 raster   ./edje-anchors                     0     3672     6050    23776
12153 raster   ./edje-anchors                     0     3672     6049    23776
12153 raster   ./edje-anchors                     0     3672     6050    23776
12153 raster   ./edje-anchors                     0     3672     6050    23776
12153 raster   ./edje-anchors                     0     3672     6050    23776
12153 raster   ./edje-anchors                     0     3672     6050    23776
12153 raster   ./edje-anchors                     0     3672     6050    23776
12153 raster   ./edje-anchors                     0     3672     6050    23776
12153 raster   ./edje-anchors                     0     3672     6050    23776
12153 raster   ./edje-anchors                     0     3672     6050    23776
12153 raster   ./edje-anchors                     0     3672     6050    23776

...

I hold down the a key so its creating and destroying. Memory usage is stable.
Yes - it goes up and down a bit as when you malloc and free the libc
implementation may move things around and allocate things a bit differently
based on alloc/free patterns. USS is private dirty pages and mmaped files/libs
that are unique to that process alone. PSS is proportional memory usage. so if
this process mmaps the same file (e.g. data file or shared lib) as other
processes this gets a proportional hit for that (e.g. if libc is mmaped by 100
processes, this will allocate 1/100 of the memory mapped from libc to this
process - this is simplified as it's really per page). RSS is the last counting
all resident pages including all pages mapped in from binaries and shared libs
irrespective of how many other processes use the same thing.

So this says the same thing massif/valgrind do. Steady memory usage.

> Hi Carsten,
> I try your edje-anchors.c,  use linux comman ps to show the memory , you can
> find that the memory keep growing as shown below. I also attach the massif
> out file, if memory use is steady according to massif, why ps show the memory
> keep growing? Please advise, many thanks.
> 
> 
> 
> 
> 
> 
> 
> 
> At 2019-12-03 17:28:13, "Carsten Haitzler" <ras...@rasterman.com> wrote:
> >On Tue, 3 Dec 2019 10:03:55 +0800 (CST) Jing  <chenjing...@126.com> said:
> >
> >> Hi Carsten,
> >> You can put these files into efl-1.21.1/src/examples/edje, and use below
> >> command to complile. edje_cc -beta edje-anchors.edc animations.edc ;
> >> gcc -o edje-anchors edje-anchors.c `pkg-config --libs --cflags evas ecore
> >> ecore-evas edje`
> >
> >so this example leaks too you think? reading it... if you happen to press a
> >2 times in a row it'll leak because you will overwrite the g_viewObj variable
> >with a new object, losing the handle on the old one... i modified it by
> >adding:
> >
> >       if (g_viewObj) evas_object_del(g_viewObj);
> >
> >in 
> >
> >    if (!strcmp(ev->key, "a")) {}
> >
> >so the old object is guaranteed to be deleted before losing its handle. i
> >cleaned up the formatting and the dirname/snprintf stuff that was not
> >necessarily always going to work if argv[0] didnt have a full or relative
> >path in it O(just referring to the file as ./edje-anchors.edj would do fine)
> >and removed some pointless casts (casting to/from void * doesn't need an
> >explicit cast in C)... I ended up with the attached source file and massif
> >tells me this when i hold down the a key for a while which adds and deletes:
> >
> >http://www.enlightenment.org/ss/e-5de62650098be9.83426512.png
> >
> >that's a pretty steady memory use. it grows a bit as things get loaded up,
> >llists gets filled and emptied and memory pools get filled up and allocated
> >(the memory pools exist to avoid more allocations going through libc since we
> >allocate many objects of the same size so we have our own pools we pull
> >allocations from).
> >
> >i also remember to set the object handle to null after deletion with the "d"
> >key so pressing "d" twice doesn't end up with trying to delete an invalid
> >object handle... and of course pressing a twice in a row doesn't result in a
> >leak now too.
> >
> >> I also attach the massif output file, please help to check,  many thanks.
> >> 
> >> At 2019-12-03 03:57:44, "Carsten Haitzler" <ras...@rasterman.com> wrote:
> >> >On Mon, 2 Dec 2019 20:23:08 +0800 (CST) Jing  <chenjing...@126.com> said:
> >> >
> >> >> Hi Carsten,
> >> >> Please find attached efl demo,  i press key "a" to call
> >> >> edje_object_add(obj) and edje_object_file_set(obj, animations.edj,
> >> >> group),  and then press  key "d" to evas_object_del(obj), repeat press
> >> >> "a" and "b" several times,  use linux comman ps to show the memory ,
> >> >> you can find that the memory keep growing as shown below.  These memory
> >> >> will not free until device reboot. Please help to advise, many thanks.
> >> >
> >> >can you send me a compileable demo app too? also ... have you tried
> >> >valgrind
> >> >+ massif as i suggested?
> >> >
> >> >there is nothing in an edje file that should cause any leak. i suspect the
> >> >problem is somewhere else - (if there even is a leak) so... if you send
> >> >that i can look and see.
> >> >
> >> >> At 2019-12-02 19:05:00, "Carsten Haitzler" <ras...@rasterman.com> wrote:
> >> >> >On Mon, 2 Dec 2019 16:11:32 +0800 (CST) Jing  <chenjing...@126.com>
> >> >> >said:
> >> >> >
> >> >> >> Hi Carsten,
> >> >> >> Currently, when enter a layout , my program will  use
> >> >> >> edje_object_add() to add an object, and then use
> >> >> >> edje_object_file_set() to define the layout by EDC file, the object
> >> >> >> will saved into stack, when exit from the layout, then will use
> >> >> >> evas_object_del() to delete the object. A same layout, i enter and
> >> >> >> exit several times, the memory will keep growing. For example, the
> >> >> >> initial memory is A,
> >> >> >> 1.  After first time enter and exit, the memory will grow to B
> >> >> >> 2.  On the second try enter, the memory still B, but after exit, the
> >> >> >> memory will grow to C.  ---Why ?? Please help to advise how to fix
> >> >> >> this issue.
> >> >> >
> >> >> >It should not keep growing. I don't know why you see this. If you use
> >> >> >valgrind+massif and massif-visualizer you will be able to start finding
> >> >> >out what is growing. you need to force it to grow a lot to really see
> >> >> >(so just keep triggering the loop and making it leak until the leak is
> >> >> >big).
> >> >> >
> >> >> >efl has lots of caching behind the scenes. we store lots of data in
> >> >> >global caches so to some extent memory can grow a bit (up to a limit)
> >> >> >due to this. it all depends on the situation.
> >> >> >
> >> >> >> Besides, I don't quite understand your below saying,  do you have
> >> >> >> demo for it ?   
> >> >> >
> >> >> >if you do what i described below in a for loop the evas objects will
> >> >> >not be deleted when evas_object_del is called. the deletion is delayed
> >> >> >until the whole mainloop has gone through a few cycles (evas has
> >> >> >rendered at least 2 or 3 frames of updates) THEN the objects get
> >> >> >deleted. they are queued a marked for deletion and will later be
> >> >> >deleted... but it takes some time and some rendering to do that.
> >> >> >objects have to stay around for a few render cycles due to evas having
> >> >> >to calculate previous+current update regions. the objects have to stay
> >> >> >there so the difference can be calculated. if an object is deleted
> >> >> >when you call evas_object_del() then there is no object to use to
> >> >> >calculate the difference between previous and current frame.
> >> >> >
> >> >> >> "your memory will keep growing ad the objects will be queued for
> >> >> >> deletion after 2 more renders. you would need the main loop to go
> >> >> >> idle *AND* for there to be visible changes in the canvas needing
> >> >> >> rendering. evas_norender(evas); exists for these cases where you do
> >> >> >> a loop where you add/del objects and never show them or have them
> >> >> >> rendered (and just use the canvas as a workbench). this forces a "no
> >> >> >> rendering" render cycle that will clean up queued objects.
> >> >> >> 
> >> >> >> it's exceedingly rare to do the above without having your canvas go
> >> >> >> through some rendering at some point.
> >> >> >> 
> >> >> >> also edje will QUEUE signals and process them in idle time. if there
> >> >> >> is never any idle time in the ecore mainloop then the signals will
> >> >> >> just queue up and not be processed. setting a file will produce some
> >> >> >> signals already (like "load" "")."
> >> >> >> 
> >> >> >> 
> >> >> >> At 2019-11-30 00:45:26, "Carsten Haitzler" <ras...@rasterman.com>
> >> >> >> wrote:
> >> >> >> >On Fri, 29 Nov 2019 09:10:05 +0800 (CST) Jing  <chenjing...@126.com>
> >> >> >> >said:
> >> >> >> >
> >> >> >> >> OK, Carsten, please help to check my code flow, Is there anything
> >> >> >> >> wrong? Please advise, thanks.
> >> >> >> >
> >> >> >> >there is nothing wrong with it. hiding isn't needed as deletion
> >> >> >> >already hides... it might be smarter to show after you have moved
> >> >> >> >and resized and set layer to avoid extra events, but nothing really
> >> >> >> >is wrong there.
> >> >> >> >
> >> >> >> >have you used valgrind and massif to crack memory usage, then
> >> >> >> >massif-visualizer to view it?
> >> >> >> >
> >> >> >> >> 在 2019-11-29 05:16:23,"Carsten Haitzler" <ras...@rasterman.com>
> >> >> >> >> 写道:
> >> >> >> >> >On Thu, 28 Nov 2019 20:14:53 +0800 (CST) Jing
> >> >> >> >> ><chenjing...@126.com> said:
> >> >> >> >> >
> >> >> >> >> >> Thanks Carsten,
> >> >> >> >> >> 
> >> >> >> >> >> 
> >> >> >> >> >> I did not find edje_object_del(), did you mean
> >> >> >> >> >> evas_object_del()?
> >> >> >> >> >
> >> >> >> >> >sorry - my typo. evas_object_del();
> >> >> >> >> >
> >> >> >> >> >> Here is my code flow:
> >> >> >> >> >> //enter:
> >> >> >> >> >> obj = edje_object_add(evas)
> >> >> >> >> >> edje_object_file_set(obj, file , grup)
> >> >> >> >> >> evas_object_show(obj )
> >> >> >> >> >> evas_object_move()
> >> >> >> >> >> evas_object_resize()
> >> >> >> >> >> evas_object_focus_set()
> >> >> >> >> >> evas_object_layer_set()
> >> >> >> >> >> //exit:
> >> >> >> >> >> evas_object_hide(obj)
> >> >> >> >> >> evas_object_del(obj)
> >> >> >> >> >> Is there anything wrong? Please advise, thanks.
> >> >> >> >> >> 
> >> >> >> >> >> At 2019-11-28 17:21:38, "Carsten Haitzler (The Rasterman)"
> >> >> >> >> >> <ras...@rasterman.com> wrote:
> >> >> >> >> >> >On Thu, 28 Nov 2019 15:43:17 +0800 (CST) Jing
> >> >> >> >> >> ><chenjing...@126.com> said:
> >> >> >> >> >> >
> >> >> >> >> >> >> Thanks Hermet for you reply.
> >> >> >> >> >> >> 
> >> >> >> >> >> >> 
> >> >> >> >> >> >> In my test, i find that if i call function
> >> >> >> >> >> >> edje_object_file_set(Edje_Object *obj, const char *file,
> >> >> >> >> >> >> const char *group), even i call evas_object_del(Edje_Object
> >> >> >> >> >> >> *obj); to delete the obj, the memory of my program will
> >> >> >> >> >> >> keep growing, if i am not use edje_object_file_set() then
> >> >> >> >> >> >> this issue will not exists.  Is there a way to free the
> >> >> >> >> >> >> memory of edje_object_file_set() ? Please advise, thanks.
> >> >> >> >> >> >
> >> >> >> >> >> >Memory will be freed... is it possible you are not getting any
> >> >> >> >> >> >rendering happening? e.g. if you do something like:
> >> >> >> >> >> >
> >> >> >> >> >> >for (i = 0; i < 100000; i++) {
> >> >> >> >> >> >  o = edje_object_add(evas);
> >> >> >> >> >> >  edje_object_del(o);
> >> >> >> >> >> >}
> >> >> >> >> >> >
> >> >> >> >> >> >your memory will keep growing ad the objects will be queued
> >> >> >> >> >> >for deletion after 2 more renders. you would need the main
> >> >> >> >> >> >loop to go idle *AND* for there to be visible changes in the
> >> >> >> >> >> >canvas needing rendering. evas_norender(evas); exists for
> >> >> >> >> >> >these cases where you do a loop where you add/del objects and
> >> >> >> >> >> >never show them or have them rendered (and just use the
> >> >> >> >> >> >canvas as a workbench). this forces a "no rendering" render
> >> >> >> >> >> >cycle that will clean up queued objects.
> >> >> >> >> >> >
> >> >> >> >> >> >it's exceedingly rare to do the above without having your
> >> >> >> >> >> >canvas go through some rendering at some point.
> >> >> >> >> >> >
> >> >> >> >> >> >also edje will QUEUE signals and process them in idle time. if
> >> >> >> >> >> >there is never any idle time in the ecore mainloop then the
> >> >> >> >> >> >signals will just queue up and not be processed. setting a
> >> >> >> >> >> >file will produce some signals already (like "load" "").
> >> >> >> >> >> >
> >> >> >> >> >> >> At 2019-11-26 12:24:45, "Hermet Park" <hermetp...@gmail.com>
> >> >> >> >> >> >> wrote:
> >> >> >> >> >> >> >Once object is deleted, the subsequent memory belonging to
> >> >> >> >> >> >> >the object will be removed as well.
> >> >> >> >> >> >> >You don't need to care about it. Callbacks neither.
> >> >> >> >> >> >> >
> >> >> >> >> >> >> >On Mon, Nov 25, 2019 at 9:12 PM Jing <chenjing...@126.com>
> >> >> >> >> >> >> >wrote:
> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> Hi all,
> >> >> >> >> >> >> >> I have some memory free questions when using below two
> >> >> >> >> >> >> >> functions:
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> 1.  EAPI Eina_Bool edje_object_file_set(Evas_Object *obj,
> >> >> >> >> >> >> >> const char *file, const char *group);
> >> >> >> >> >> >> >> ---  After this function done,  i will call
> >> >> >> >> >> >> >> evas_object_del (obj) to delete the obj,  anything else
> >> >> >> >> >> >> >> that i need to free ? For example, the edj file used in
> >> >> >> >> >> >> >> this funciton?
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> 2.  evas_object_event_callback_add(Evas_Object *eo_obj,
> >> >> >> >> >> >> >> Evas_Callback_Type type, Evas_Object_Event_Cb func, const
> >> >> >> >> >> >> >> void *data)
> >> >> >> >> >> >> >> ---- After this function done,  i will call
> >> >> >> >> >> >> >> evas_object_del (obj) to delete the obj,   the callback
> >> >> >> >> >> >> >> will be auto deleted after evas_object_del or  i have to
> >> >> >> >> >> >> >> use evas_object_event_callback_del(Evas_Object *eo_obj,
> >> >> >> >> >> >> >> Evas_Callback_Type type, Evas_Object_Event_Cb func) to
> >> >> >> >> >> >> >> delete ?
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> Thanks.
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> _______________________________________________
> >> >> >> >> >> >> >> enlightenment-devel mailing list
> >> >> >> >> >> >> >> enlightenment-devel@lists.sourceforge.net
> >> >> >> >> >> >> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >
> >> >> >> >> >> >> >
> >> >> >> >> >> >> >-- 
> >> >> >> >> >> >> >Regards, Hermet
> >> >> >> >> >> >> >
> >> >> >> >> >> >> >_______________________________________________
> >> >> >> >> >> >> >enlightenment-devel mailing list
> >> >> >> >> >> >> >enlightenment-devel@lists.sourceforge.net
> >> >> >> >> >> >> >https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >> >> >> >> >> >> 
> >> >> >> >> >> >> _______________________________________________
> >> >> >> >> >> >> enlightenment-devel mailing list
> >> >> >> >> >> >> enlightenment-devel@lists.sourceforge.net
> >> >> >> >> >> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >> >> >> >> >> >> 
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >> >-- 
> >> >> >> >> >> >------------- Codito, ergo sum - "I code, therefore I am"
> >> >> >> >> >> >-------------- Carsten Haitzler - ras...@rasterman.com
> >> >> >> >> >> 
> >> >> >> >> >> _______________________________________________
> >> >> >> >> >> enlightenment-devel mailing list
> >> >> >> >> >> enlightenment-devel@lists.sourceforge.net
> >> >> >> >> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >-- 
> >> >> >> >> >------------- Codito, ergo sum - "I code, therefore I am"
> >> >> >> >> >-------------- Carsten Haitzler - ras...@rasterman.com
> >> >> >> >
> >> >> >> >
> >> >> >> >-- 
> >> >> >> >------------- Codito, ergo sum - "I code, therefore I am"
> >> >> >> >-------------- Carsten Haitzler - ras...@rasterman.com
> >> >> >> 
> >> >> >> _______________________________________________
> >> >> >> enlightenment-devel mailing list
> >> >> >> enlightenment-devel@lists.sourceforge.net
> >> >> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >> >> >
> >> >> >
> >> >> >-- 
> >> >> >------------- Codito, ergo sum - "I code, therefore I am"
> >> >> >-------------- Carsten Haitzler - ras...@rasterman.com
> >> >
> >> >
> >> >-- 
> >> >------------- Codito, ergo sum - "I code, therefore I am" --------------
> >> >Carsten Haitzler - ras...@rasterman.com
> >
> >
> >-- 
> >------------- Codito, ergo sum - "I code, therefore I am" --------------
> >Carsten Haitzler - ras...@rasterman.com
> >


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - ras...@rasterman.com



_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to