On Thu, Feb 11, 2010 at 3:10 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Thu, 11 Feb 2010 14:29:53 +0800 Brett Nash <n...@nash.id.au> said: > >> On Thu, 11 Feb 2010 11:35:26 +0800 >> Brian Wang <brian.wang.0...@gmail.com> wrote: >> >> > Hello all, >> > >> > I'm using Elementary with recent svn. I got lots of valgrind memory >> > check warning at program exit such as: >> > >> > ==6296== 5 bytes in 1 blocks are possibly lost in loss record 10 of >> > 1,788 ==6296== at 0x4024C1C: malloc (vg_replace_malloc.c:195) >> > ==6296== by 0x429FC8F: strdup (strdup.c:43) >> > ==6296== by 0x406A19E: evas_key_modifier_add (evas_key.c:172) >> > ==6296== by 0x47355EC: ecore_event_window_register >> > (ecore_input_evas.c:88) ==6296== by 0x4180B73: >> > ecore_evas_software_x11_new (ecore_evas_x.c:2603) ==6296== by >> > 0x41CA91A: elm_win_add (elm_win.c:361) ==6296== by 0x80500B3: >> > win_standard_populate (app.c:2036) ==6296== by 0x8050570: >> > win_mode_player_populate_delay (app.c:2148) ==6296== by 0x8050646: >> > win_mode_switch (app.c:2193) ==6296== by 0x805074E: >> > startup_win_init (app.c:2241) ==6296== by 0x80508AC: elm_main >> > (app.c:2283) ==6296== by 0x80508EA: main (app.c:2292) >> > >> > >> > ==6296== 8 bytes in 1 blocks are possibly lost in loss record 59 of >> > 1,788 ==6296== at 0x4023F5B: calloc (vg_replace_malloc.c:418) >> > ==6296== by 0x4084B38: evas_object_rectangle_new >> > (evas_object_rectangle.c:134) >> > ==6296== by 0x4084A13: evas_object_rectangle_init >> > (evas_object_rectangle.c:109) >> > ==6296== by 0x40849E1: evas_object_rectangle_add >> > (evas_object_rectangle.c:95) ==6296== by 0x41EB134: elm_pager_add >> > (elm_pager.c:222) ==6296== by 0x804E4E1: control_pager_add >> > (app.c:1264) ==6296== by 0x80505A8: win_mode_player_populate_delay >> > (app.c:2156) ==6296== by 0x8050646: win_mode_switch (app.c:2193) >> > ==6296== by 0x805074E: startup_win_init (app.c:2241) >> > ==6296== by 0x80508AC: elm_main (app.c:2283) >> > ==6296== by 0x80508EA: main (app.c:2292) >> > ==6296== >> > ==6296== 8 bytes in 1 blocks are possibly lost in loss record 60 of >> > 1,788 ==6296== at 0x4023F5B: calloc (vg_replace_malloc.c:418) >> > ==6296== by 0x4084B38: evas_object_rectangle_new >> > (evas_object_rectangle.c:134) >> > ==6296== by 0x4084A13: evas_object_rectangle_init >> > (evas_object_rectangle.c:109) >> > ==6296== by 0x40849E1: evas_object_rectangle_add >> > (evas_object_rectangle.c:95) ==6296== by 0x41EB171: elm_pager_add >> > (elm_pager.c:226) ==6296== by 0x804E4E1: control_pager_add >> > (app.c:1264) ==6296== by 0x80505A8: win_mode_player_populate_delay >> > (app.c:2156) ==6296== by 0x8050646: win_mode_switch (app.c:2193) >> > ==6296== by 0x805074E: startup_win_init (app.c:2241) >> > ==6296== by 0x80508AC: elm_main (app.c:2283) >> > ==6296== by 0x80508EA: main (app.c:2292) >> > ==6296== >> > ==6296== 8 bytes in 1 blocks are possibly lost in loss record 61 of >> > 1,788 ==6296== at 0x4023F5B: calloc (vg_replace_malloc.c:418) >> > ==6296== by 0x4084B38: evas_object_rectangle_new >> > (evas_object_rectangle.c:134) >> > ==6296== by 0x4084A13: evas_object_rectangle_init >> > (evas_object_rectangle.c:109) >> > ==6296== by 0x40849E1: evas_object_rectangle_add >> > (evas_object_rectangle.c:95) ==6296== by 0x43E532E: _edje_add >> > (edje_main.c:211) ==6296== by 0x43E86F8: _edje_smart_add >> > (edje_smart.c:65) ==6296== by 0x4085D83: evas_object_smart_add >> > (evas_object_smart.c:346) ==6296== by 0x43E86D4: edje_object_add >> > (edje_smart.c:56) ==6296== by 0x41D1A75: elm_button_add >> > (elm_button.c:222) ==6296== by 0x804C6B6: button_add (app.c:442) >> > ==6296== by 0x804E2FD: elapsed_bar_add (app.c:1228) >> > ==6296== by 0x804E535: control_pager_add (app.c:1270) >> > >> > There are lots of more. The summary is quite scary: >> > ==6671== LEAK SUMMARY: >> > ==6671== definitely lost: 1,016 bytes in 12 blocks >> > ==6671== indirectly lost: 4,340 bytes in 217 blocks >> > ==6671== possibly lost: 2,915,620 bytes in 5,119 blocks >> > ==6671== still reachable: 584,490 bytes in 6,969 blocks >> > ==6671== suppressed: 0 bytes in 0 blocks >> > >> > I'm not sure how possible "possibly lost" means. Is it safe to >> > ignore? I believe those warnings were not there. But my memory might >> > be at fault. >> >> Possibly lost means it wasn't freed at exit generally. >> >> Ignore them. The OS is a hell of a lot better (and faster) at cleaning >> such things up[1]. >> >> Regards, >> nash >> >> [1] Deleting an entire address space is great cleanup method[2] ;-) >> [2] And doesn't need you to thrash your TLB and swap following free >> memory lists too. > > you said it for me. the onyl things to really worry about are the definitely > losts. indirectly lost - cant remember. need to check. as such the definitely > losts in efl are quite small and limited to 1-offs. if they were recurring - > they'd be fixed.
OK. Though, it's quite troubling as the actual leaks may blend into the massive listing of valgrind output. Those warnings were not there and that's bugging me. > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > -- brian ------------------ Cool-Karaoke - The smallest recording studio, in your palm, open-sourced http://cool-idea.com.tw/ iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
