On Sat, 03 Dec 2016 01:45:30 +0000 Gustavo Sverzut Barbieri <barbi...@gmail.com> said:
> Well, I did force and it "worked". Not much test, like I've noticed some > cases check for class using just the eo_id... how can you force it? literally there's missing non-eoid code paths. eo will mess up the pointer by mucking about with the bits in it... i'm amazed it worked at all.. but i guarantee you it wont be correct either way. > Em sex, 2 de dez de 2016 às 23:31, Carsten Haitzler <ras...@rasterman.com> > escreveu: > > > On Fri, 2 Dec 2016 22:24:19 -0200 Gustavo Sverzut Barbieri < > > barbi...@gmail.com> > > said: > > > > > On Fri, Dec 2, 2016 at 10:14 PM, Cedric BAIL <cedric.b...@free.fr> > > wrote: > > > > On Fri, Dec 2, 2016 at 3:17 PM, Gustavo Sverzut Barbieri > > > > <barbi...@gmail.com> wrote: > > > >> barbieri pushed a commit to branch master. > > > >> > > > >> > > http://git.enlightenment.org/core/efl.git/commit/?id=227463bdde43bc9095b75f4ef19f9fef9a742f04 > > > >> > > > >> commit 227463bdde43bc9095b75f4ef19f9fef9a742f04 > > > >> Author: Gustavo Sverzut Barbieri <barbi...@profusion.mobi> > > > >> Date: Fri Dec 2 20:48:37 2016 -0200 > > > >> > > > >> eo: allow valgrind-like tracking of object lifecycle. > > > >> > > > >> Eo pointer indirection is super nice as it avoids you to access > > > >> invalid memory, but this extra checks inhibits valgrind's own > > tracking > > > >> of memory lifecycle, usually it would report when the object was > > > >> created and when the object is deleted, both as stack traces. > > > >> > > > >> This commits introduces logging of object creation and destruction > > > >> under its own eina_log_domain and controlled by > > EO_LIFECYCLE_DEBUG and > > > >> EO_LIFECYCLE_NO_DEBUG envvars. These will only be available if > > > >> compiled with EO_DEBUG, thus shouldn't cause any performance hits > > on > > > >> production code. > > > > > > > > I haven't looked at it, but wouldn't it be also possible to integrate > > > > it with valgrind directly using valgrind macro ? > > > > > > I did not look either, I find it useful even without valgrind, but > > > indeed when running inside valgrind it could be nice one. > > > > > > Maybe it's possible, I need to check the valgrind calls as they have > > > no knowledge about the eo_id... and that's what we check, if disabling > > > pointer indirection (undef HAVE_EO_ID), then valgrind will catch it > > > even with eina_safety. > > > > you cant disable eoid anymore. we need too many bits for metadata now. > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > 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" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
