Re: [E-devel] E SVN: raster trunk/terminology/src/bin

[Gustavo S. B. <bar...@pr...>]

BTW, is it a leak in valgrind? Or there are still some pointers to that
(possibly lost?)

On Saturday, January 5, 2013, Carsten Haitzler wrote:

> On Sat, 5 Jan 2013 15:50:30 +0900 Cedric BAIL <ced...@fr...<javascript:;>>
> said:
>
> > On Sat, Jan 5, 2013 at 3:40 PM, Carsten Haitzler <ra...@ra...<javascript:;>>
> wrote:
> > > On Fri, 4 Jan 2013 11:09:35 -0200 Lucas De Marchi
> > > <luc...@pr... <javascript:;>> said:
> > >> On Fri, Dec 28, 2012 at 10:25 AM, Carsten Haitzler <
> ra...@ra... <javascript:;>>
> > >> wrote:
> > >> > On Fri, 28 Dec 2012 01:58:49 -0200 Lucas De Marchi
> > >> > <luc...@pr... <javascript:;>> said:
> > >> >
> > >> >> On Fri, Dec 28, 2012 at 12:28 AM, Enlightenment SVN
> > >> >> <no-...@en... <javascript:;>> wrote:
> > >> >> > Log:
> > >> >> > work around edbus issues by forcing the mainloop to run at least
> one
> > >> >> >   cycle with some dummy things... in ipc launch mode.
> > >> >> >
> > >> >> >   also make selection jump to end if a newline is there - as
> disussed
> > >> >> > on ml.
> > >> >>
> > >> >> could you detail a little bit what is the issue. Looking at the
> code,
> > >> >> I couldn't understand why you put all this ipc stuff, instead of
> doing
> > >> >> something like eve does.
> > >> >
> > >> > leak here:
> > >> >
> > >> > ==23628== 120 (64 direct, 56 indirect) bytes in 1 blocks are
> definitely
> > >> > lost in loss record 70 of 107
> > >> > ==23628==    at 0x4C29E84: calloc
> > >> > (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==23628==
>    by
> > >> > 0xB48344F: edbus_connection_name_get (edbus_core.c:476) ==23628==
>  by
> > >> > 0xB482EA8: edbus_connection_name_object_set (edbus_core.c:413)
> ==23628==
> > >> > by 0xB48DF6B: edbus_object_get (edbus_object.c:211) ==23628==    by
> > >> > 0xB484E7A: _connection_get (edbus_core.c:941) ==23628==    by
> 0xB484FC1:
> > >> > edbus_connection_get (edbus_core.c:968) ==23628==    by 0x8233529:
> > >> > efreet_cache_init (efreet_cache.c:129) ==23628==    by 0x822433D:
> > >> > efreet_init (efreet.c:78) ==23628==    by 0x4F28E2F: elm_need_efreet
> > >> > (elm_main.c:449) ==23628==    by 0x408CCA: config_init (config.c:24)
> > >> > ==23628==    by 0x40DA1B: elm_main (main.c:1003)
> > >> > ==23628==    by 0x40E7FB: main (main.c:1322)
> > >> > ==23628==
> > >>
> > >> we fixed this one... could you confirm it's ok now?
> > >
> > > yup. this one is gone... now you can look at the wonderful evas async
> > > leak... i have a terminology using 6gb... :) pretty impressive if you
> ask
> > > me! :)
> >
> > Interestingly enough I don't see that bug in Terminology, but my
> > Enlightenment is leaking fast and over one night it does have a crazy
> > 1.5GB memory usage. I believe the issue are related.
>
> i enabled multi-instance and just ran rebuilds of efl on 6 different
> machines... a lot of scrolling... similar test to what valgrind log i
> showed
> with 700m usage.
>
>
> --
> ------------- Codito, ergo sum - "I code, therefore I am" --------------
> The Rasterman (Carsten Haitzler)    ra...@ra... <javascript:;>
>
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122912
> _______________________________________________
> enlightenment-devel mailing list
> enl...@li... <javascript:;>
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>


-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: bar...@gm...
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202