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. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
