Re: [E-devel] [EGIT] [core/efl] master 03/03: eo: allow valgrind-like tracking of object lifecycle.

2016-12-06 Thread Gustavo Sverzut Barbieri 
hi all,

since now eo_debug will have -h/--help, -l/--lifecycle-debug and
-L/--lifecycle-no-debug. As --help says:

Usage:

./src/scripts/eo/eo_debug [options]  [executable parameters]

Options:
-l, --lifecycle-debug[=class1,class2]   Turn on debug for object
lifecycle, optionally provides
a whitelist of classes to
be allowed.
-L, --lifecycle-no-debug=class1,class2  Disable lifecycle for the
selected classes.
-h, --help  This message.


It will also use eina_btlog by default on its output, this makes user
life much easier as he will see real function names, files and lines.


On Mon, Dec 5, 2016 at 1:30 AM, Gustavo Sverzut Barbieri
 wrote:
> On Sun, Dec 4, 2016 at 11:19 PM, Jean-Philippe André  
> wrote:
>> Hi Gustavo,
>>
>> On 3 December 2016 at 08:17, Gustavo Sverzut Barbieri 
>> wrote:
>>
>>> barbieri pushed a commit to branch master.
>>>
>>> http://git.enlightenment.org/core/efl.git/commit/?id=227463b
>>> dde43bc9095b75f4ef19f9fef9a742f04
>>>
>>> commit 227463bdde43bc9095b75f4ef19f9fef9a742f04
>>> Author: Gustavo Sverzut Barbieri 
>>> 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.
>>>
>>
>> So this should basically be used in conjunction with the existing eo_debug
>> infrastructure?
>> Why not improve eo_debug itself? (eg. add options to the script)
>
> yes, you need eo_debug (libeo_dbg.so). You mean some options to
> eo_debug and then it would export these envvars? sounds ok
>
>
> --
> Gustavo Sverzut Barbieri
> --
> Mobile: +55 (16) 99354-9890



-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 03/03: eo: allow valgrind-like tracking of object lifecycle.

2016-12-04 Thread Gustavo Sverzut Barbieri 
On Sun, Dec 4, 2016 at 11:19 PM, Jean-Philippe André  wrote:
> Hi Gustavo,
>
> On 3 December 2016 at 08:17, Gustavo Sverzut Barbieri 
> wrote:
>
>> barbieri pushed a commit to branch master.
>>
>> http://git.enlightenment.org/core/efl.git/commit/?id=227463b
>> dde43bc9095b75f4ef19f9fef9a742f04
>>
>> commit 227463bdde43bc9095b75f4ef19f9fef9a742f04
>> Author: Gustavo Sverzut Barbieri 
>> 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.
>>
>
> So this should basically be used in conjunction with the existing eo_debug
> infrastructure?
> Why not improve eo_debug itself? (eg. add options to the script)

yes, you need eo_debug (libeo_dbg.so). You mean some options to
eo_debug and then it would export these envvars? sounds ok


-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

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

Re: [E-devel] [EGIT] [core/efl] master 03/03: eo: allow valgrind-like tracking of object lifecycle.

2016-12-04 Thread Jean-Philippe André 
Hi Gustavo,

On 3 December 2016 at 08:17, Gustavo Sverzut Barbieri 
wrote:

> barbieri pushed a commit to branch master.
>
> http://git.enlightenment.org/core/efl.git/commit/?id=227463b
> dde43bc9095b75f4ef19f9fef9a742f04
>
> commit 227463bdde43bc9095b75f4ef19f9fef9a742f04
> Author: Gustavo Sverzut Barbieri 
> 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.
>

So this should basically be used in conjunction with the existing eo_debug
infrastructure?
Why not improve eo_debug itself? (eg. add options to the script)

> [snap]

Best regards,

-- 
Jean-Philippe André
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 03/03: eo: allow valgrind-like tracking of object lifecycle.

2016-12-03 Thread The Rasterman 
On Sat, 3 Dec 2016 09:58:20 -0200 Gustavo Sverzut Barbieri 
said:

> On Sat, Dec 3, 2016 at 12:31 AM, Carsten Haitzler 
> wrote:
> > On Sat, 03 Dec 2016 01:45:30 + Gustavo Sverzut Barbieri
> >  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.
> 
> go to eo_private.h and do:
> 
> #undef HAVE_EO_ID
> 
> I've tested with efl_net_dialer_simple_example, which does lots of
> objects and classes and inheritance. You get the following log when
> using that and the double free case:
> 
> $ LD_PRELOAD=src/lib/eo/.libs/libeo_dbg.so \
>EO_LIFECYCLE_NO_DEBUG=Efl_Loop_Timer,Efl_Promise,Efl_Future \
>EO_LIFECYCLE_DEBUG=1 \
>EINA_LOG_LEVELS=eo:3,eo_lifecycle:4 \
>libtool --mode=execute valgrind
> ./src/examples/ecore/efl_net_dialer_simple_example tcp localhost:1234
> 
> DBG<13298>:eo_lifecycle lib/eo/eo.c:2736 _eo_log_obj_init() will log
> all object allocation and free
> DBG<13298>:eo_lifecycle lib/eo/eo.c:2812 _eo_log_obj_init() will NOT
> log class 'Efl_Future'
> DBG<13298>:eo_lifecycle lib/eo/eo.c:2812 _eo_log_obj_init() will NOT
> log class 'Efl_Promise'
> DBG<13298>:eo_lifecycle lib/eo/eo.c:2812 _eo_log_obj_init() will NOT
> log class 'Efl_Loop_Timer'
> DBG<13298>:eo_lifecycle lib/eo/eo.c:2689 _eo_log_obj_new() new
> obj=0x9723470 obj_id=0x9723470 class=0x9722bb0 (Efl_Vpath_Core)
> [0.1132]
> DBG<13298>:eo_lifecycle lib/eo/eo.c:2689 _eo_log_obj_new() new
> obj=0x9738a90 obj_id=0x9738a90 class=0x9737800 (Efl_Loop) [0.1645]
> DBG<13298>:eo_lifecycle lib/eo/eo.c:2689 _eo_log_obj_new() new
> obj=0x9782250 obj_id=0x9782250 class=0x97809f0 (Efl_Net_Dialer_Simple)
> [0.5570]
> DBG<13298>:eo_lifecycle lib/eo/eo.c:2689 _eo_log_obj_new() new
> obj=0x9782650 obj_id=0x9782650 class=0x977c210 (Efl_Net_Dialer_Tcp)
> [0.5736]
> DBG<13298>:eo_lifecycle lib/eo/eo.c:2689 _eo_log_obj_new() new
> obj=0x9783de0 obj_id=0x9783de0 class=0x9782930 (Efl_Io_Queue) [0.5963]
> DBG<13298>:eo_lifecycle lib/eo/eo.c:2689 _eo_log_obj_new() new
> obj=0x9786360 obj_id=0x9786360 class=0x97841a0 (Efl_Io_Copier)
> [0.6090]
> DBG<13298>:eo_lifecycle lib/eo/eo.c:2689 _eo_log_obj_new() new
> obj=0x978bb70 obj_id=0x978bb70 class=0x9782930 (Efl_Io_Queue) [0.6553]
> DBG<13298>:eo_lifecycle lib/eo/eo.c:2689 _eo_log_obj_new() new
> obj=0x978bf30 obj_id=0x978bf30 class=0x97841a0 (Efl_Io_Copier)
> [0.6588]
> INFO: sending 'Hello World!'
> DBG<13298>:eo_lifecycle lib/eo/eo.c:2712 _eo_log_obj_free() free
> obj=0x978bb70 obj_id=0x978bb70 class=0x9782930 (Efl_Io_Queue) [0.7322]
> DBG<13298>:eo_lifecycle lib/eo/eo.c:2712 _eo_log_obj_free() free
> obj=0x978bf30 obj_id=0x978bf30 class=0x97841a0 (Efl_Io_Copier)
> [0.7472]
> DBG<13298>:eo_lifecycle lib/eo/eo.c:2712 _eo_log_obj_free() free
> obj=0x9783de0 obj_id=0x9783de0 class=0x9782930 (Efl_Io_Queue) [0.7504]
> DBG<13298>:eo_lifecycle lib/eo/eo.c:2712 _eo_log_obj_free() free
> obj=0x9786360 obj_id=0x9786360 class=0x97841a0 (Efl_Io_Copier)
> [0.7536]
> DBG<13298>:eo_lifecycle lib/eo/eo.c:2712 _eo_log_obj_free() free
> obj=0x9782650 obj_id=0x9782650 class=0x977c210 (Efl_Net_Dialer_Tcp)
> [0.7730]
> DBG<13298>:eo_lifecycle lib/eo/eo.c:2712 _eo_log_obj_free() free
> obj=0x9782250 obj_id=0x9782250 class=0x97809f0 (Efl_Net_Dialer_Simple)
> [0.7936]
> CRI<13298>: ../src/lib/eo/efl_object.eo.c:78 efl_del() *** Eina Magic
> Check Failed at 0x9782250 !!!
> Input handle is wrong type
> Expected: a186bc32 - Eo
> Supplied:  - (unknown)
> *** NAUGHTY PROGRAMMER!!!
> *** SPANK SPANK SPANK!!!
> *** Now go fix your code. Tut tut tut!
> 
> 
> ERR<13298>:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del()
> obj_id=0x9782250 created obj=0x9782250, class=0x97809f0
> (Efl_Net_Dialer_Simple) [0.5570s, 0.2536 ago]:
> ERR<13298>:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del()
> 0x0004e3ff1a: libeo_dbg.so+0x8f1a (in
> src/lib/eo/.libs/libeo_dbg.so 0x4e37000)
> ERR<13298>:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del()
> 0x0004e3fbdd: _efl_add_internal_start+0x1cd (in
> src/lib/eo/.libs/libeo_dbg.so 0x4e37000)
> ERR<13298>:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del()
> 0x10a85f: lt-efl_net_dialer_simple_example+0x285f (in
> /home/gustavo/Development/git/efl/src/examples/ecore/.libs/lt-efl_net_dialer_simple_example
> 0x108000)
> ERR<13298>:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del()
> 0x0005c79291: __libc_start_main+0xf1 (in /usr/lib/libc.so.6
> 0x5c59000)
> ERR<13298>:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del()
> 0x10a38a: _start+0x2a (in
> /home/gustavo/Development/git/efl/src/examples/ecore/.libs/lt-efl_net_dialer_simple_example
> 0x108000)
>

Re: [E-devel] [EGIT] [core/efl] master 03/03: eo: allow valgrind-like tracking of object lifecycle.

2016-12-03 Thread Gustavo Sverzut Barbieri 
On Sat, Dec 3, 2016 at 9:58 AM, Gustavo Sverzut Barbieri
 wrote:
> I've noticed no valgrind kicks in and that's due the freeq... that one
> must mark the object as dead... will do it now

sorry, eina_thrash, as eina_freeq() will bypass if running inside valgrind.


-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

--
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

Re: [E-devel] [EGIT] [core/efl] master 03/03: eo: allow valgrind-like tracking of object lifecycle.

2016-12-03 Thread Gustavo Sverzut Barbieri 
On Sat, Dec 3, 2016 at 12:31 AM, Carsten Haitzler  wrote:
> On Sat, 03 Dec 2016 01:45:30 + Gustavo Sverzut Barbieri
>  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.

go to eo_private.h and do:

#undef HAVE_EO_ID

I've tested with efl_net_dialer_simple_example, which does lots of
objects and classes and inheritance. You get the following log when
using that and the double free case:

$ LD_PRELOAD=src/lib/eo/.libs/libeo_dbg.so \
   EO_LIFECYCLE_NO_DEBUG=Efl_Loop_Timer,Efl_Promise,Efl_Future \
   EO_LIFECYCLE_DEBUG=1 \
   EINA_LOG_LEVELS=eo:3,eo_lifecycle:4 \
   libtool --mode=execute valgrind
./src/examples/ecore/efl_net_dialer_simple_example tcp localhost:1234

DBG<13298>:eo_lifecycle lib/eo/eo.c:2736 _eo_log_obj_init() will log
all object allocation and free
DBG<13298>:eo_lifecycle lib/eo/eo.c:2812 _eo_log_obj_init() will NOT
log class 'Efl_Future'
DBG<13298>:eo_lifecycle lib/eo/eo.c:2812 _eo_log_obj_init() will NOT
log class 'Efl_Promise'
DBG<13298>:eo_lifecycle lib/eo/eo.c:2812 _eo_log_obj_init() will NOT
log class 'Efl_Loop_Timer'
DBG<13298>:eo_lifecycle lib/eo/eo.c:2689 _eo_log_obj_new() new
obj=0x9723470 obj_id=0x9723470 class=0x9722bb0 (Efl_Vpath_Core)
[0.1132]
DBG<13298>:eo_lifecycle lib/eo/eo.c:2689 _eo_log_obj_new() new
obj=0x9738a90 obj_id=0x9738a90 class=0x9737800 (Efl_Loop) [0.1645]
DBG<13298>:eo_lifecycle lib/eo/eo.c:2689 _eo_log_obj_new() new
obj=0x9782250 obj_id=0x9782250 class=0x97809f0 (Efl_Net_Dialer_Simple)
[0.5570]
DBG<13298>:eo_lifecycle lib/eo/eo.c:2689 _eo_log_obj_new() new
obj=0x9782650 obj_id=0x9782650 class=0x977c210 (Efl_Net_Dialer_Tcp)
[0.5736]
DBG<13298>:eo_lifecycle lib/eo/eo.c:2689 _eo_log_obj_new() new
obj=0x9783de0 obj_id=0x9783de0 class=0x9782930 (Efl_Io_Queue) [0.5963]
DBG<13298>:eo_lifecycle lib/eo/eo.c:2689 _eo_log_obj_new() new
obj=0x9786360 obj_id=0x9786360 class=0x97841a0 (Efl_Io_Copier)
[0.6090]
DBG<13298>:eo_lifecycle lib/eo/eo.c:2689 _eo_log_obj_new() new
obj=0x978bb70 obj_id=0x978bb70 class=0x9782930 (Efl_Io_Queue) [0.6553]
DBG<13298>:eo_lifecycle lib/eo/eo.c:2689 _eo_log_obj_new() new
obj=0x978bf30 obj_id=0x978bf30 class=0x97841a0 (Efl_Io_Copier)
[0.6588]
INFO: sending 'Hello World!'
DBG<13298>:eo_lifecycle lib/eo/eo.c:2712 _eo_log_obj_free() free
obj=0x978bb70 obj_id=0x978bb70 class=0x9782930 (Efl_Io_Queue) [0.7322]
DBG<13298>:eo_lifecycle lib/eo/eo.c:2712 _eo_log_obj_free() free
obj=0x978bf30 obj_id=0x978bf30 class=0x97841a0 (Efl_Io_Copier)
[0.7472]
DBG<13298>:eo_lifecycle lib/eo/eo.c:2712 _eo_log_obj_free() free
obj=0x9783de0 obj_id=0x9783de0 class=0x9782930 (Efl_Io_Queue) [0.7504]
DBG<13298>:eo_lifecycle lib/eo/eo.c:2712 _eo_log_obj_free() free
obj=0x9786360 obj_id=0x9786360 class=0x97841a0 (Efl_Io_Copier)
[0.7536]
DBG<13298>:eo_lifecycle lib/eo/eo.c:2712 _eo_log_obj_free() free
obj=0x9782650 obj_id=0x9782650 class=0x977c210 (Efl_Net_Dialer_Tcp)
[0.7730]
DBG<13298>:eo_lifecycle lib/eo/eo.c:2712 _eo_log_obj_free() free
obj=0x9782250 obj_id=0x9782250 class=0x97809f0 (Efl_Net_Dialer_Simple)
[0.7936]
CRI<13298>: ../src/lib/eo/efl_object.eo.c:78 efl_del() *** Eina Magic
Check Failed at 0x9782250 !!!
Input handle is wrong type
Expected: a186bc32 - Eo
Supplied:  - (unknown)
*** NAUGHTY PROGRAMMER!!!
*** SPANK SPANK SPANK!!!
*** Now go fix your code. Tut tut tut!


ERR<13298>:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del()
obj_id=0x9782250 created obj=0x9782250, class=0x97809f0
(Efl_Net_Dialer_Simple) [0.5570s, 0.2536 ago]:
ERR<13298>:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del()
0x0004e3ff1a: libeo_dbg.so+0x8f1a (in
src/lib/eo/.libs/libeo_dbg.so 0x4e37000)
ERR<13298>:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del()
0x0004e3fbdd: _efl_add_internal_start+0x1cd (in
src/lib/eo/.libs/libeo_dbg.so 0x4e37000)
ERR<13298>:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del()
0x10a85f: lt-efl_net_dialer_simple_example+0x285f (in
/home/gustavo/Development/git/efl/src/examples/ecore/.libs/lt-efl_net_dialer_simple_example
0x108000)
ERR<13298>:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del()
0x0005c79291: __libc_start_main+0xf1 (in /usr/lib/libc.so.6
0x5c59000)
ERR<13298>:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del()
0x10a38a: _start+0x2a (in
/home/gustavo/Development/git/efl/src/examples/ecore/.libs/lt-efl_net_dialer_simple_example
0x108000)
ERR<13298>:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del()
obj_id=0x9782250 deleted obj=0x9782250, class=0x97809f0
(Efl_Net_Dialer_Simple) [0.7936s, 0.0169 ago]:
ERR<13298>:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del()
0x0004e406ea: libeo_dbg.so+0x96ea (in

Re: [E-devel] [EGIT] [core/efl] master 03/03: eo: allow valgrind-like tracking of object lifecycle.

2016-12-02 Thread The Rasterman 
On Sat, 03 Dec 2016 01:45:30 + Gustavo Sverzut Barbieri
 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 
> 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 
> > wrote:
> > > > On Fri, Dec 2, 2016 at 3:17 PM, Gustavo Sverzut Barbieri
> > > >  wrote:
> > > >> barbieri pushed a commit to branch master.
> > > >>
> > > >>
> > http://git.enlightenment.org/core/efl.git/commit/?id=227463bdde43bc9095b75f4ef19f9fef9a742f04
> > > >>
> > > >> commit 227463bdde43bc9095b75f4ef19f9fef9a742f04
> > > >> Author: Gustavo Sverzut Barbieri 
> > > >> 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

Re: [E-devel] [EGIT] [core/efl] master 03/03: eo: allow valgrind-like tracking of object lifecycle.

2016-12-02 Thread Gustavo Sverzut Barbieri 
Well, I did force and it "worked". Not much test, like I've noticed some
cases check for class using just the eo_id...

Em sex, 2 de dez de 2016 às 23:31, Carsten Haitzler 
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 
> wrote:
> > > On Fri, Dec 2, 2016 at 3:17 PM, Gustavo Sverzut Barbieri
> > >  wrote:
> > >> barbieri pushed a commit to branch master.
> > >>
> > >>
> http://git.enlightenment.org/core/efl.git/commit/?id=227463bdde43bc9095b75f4ef19f9fef9a742f04
> > >>
> > >> commit 227463bdde43bc9095b75f4ef19f9fef9a742f04
> > >> Author: Gustavo Sverzut Barbieri 
> > >> 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

Re: [E-devel] [EGIT] [core/efl] master 03/03: eo: allow valgrind-like tracking of object lifecycle.

2016-12-02 Thread The Rasterman 
On Fri, 2 Dec 2016 22:24:19 -0200 Gustavo Sverzut Barbieri 
said:

> On Fri, Dec 2, 2016 at 10:14 PM, Cedric BAIL  wrote:
> > On Fri, Dec 2, 2016 at 3:17 PM, Gustavo Sverzut Barbieri
> >  wrote:
> >> barbieri pushed a commit to branch master.
> >>
> >> http://git.enlightenment.org/core/efl.git/commit/?id=227463bdde43bc9095b75f4ef19f9fef9a742f04
> >>
> >> commit 227463bdde43bc9095b75f4ef19f9fef9a742f04
> >> Author: Gustavo Sverzut Barbieri 
> >> 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

Re: [E-devel] [EGIT] [core/efl] master 03/03: eo: allow valgrind-like tracking of object lifecycle.

2016-12-02 Thread Gustavo Sverzut Barbieri 
On Fri, Dec 2, 2016 at 10:14 PM, Cedric BAIL  wrote:
> On Fri, Dec 2, 2016 at 3:17 PM, Gustavo Sverzut Barbieri
>  wrote:
>> barbieri pushed a commit to branch master.
>>
>> http://git.enlightenment.org/core/efl.git/commit/?id=227463bdde43bc9095b75f4ef19f9fef9a742f04
>>
>> commit 227463bdde43bc9095b75f4ef19f9fef9a742f04
>> Author: Gustavo Sverzut Barbieri 
>> 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.


-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

--
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

Re: [E-devel] [EGIT] [core/efl] master 03/03: eo: allow valgrind-like tracking of object lifecycle.

2016-12-02 Thread Cedric BAIL 
On Fri, Dec 2, 2016 at 3:17 PM, Gustavo Sverzut Barbieri
 wrote:
> barbieri pushed a commit to branch master.
>
> http://git.enlightenment.org/core/efl.git/commit/?id=227463bdde43bc9095b75f4ef19f9fef9a742f04
>
> commit 227463bdde43bc9095b75f4ef19f9fef9a742f04
> Author: Gustavo Sverzut Barbieri 
> 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 ?
-- 
Cedric BAIL

--
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