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

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

2016-12-02 Thread Gustavo Sverzut Barbieri 
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.

Running a bogus app with invalid efl_class_name_get() and double
efl_del() will report as below:

```sh
$ export EO_LIFECYCLE_NO_DEBUG=Efl_Loop_Timer,Efl_Promise,Efl_Future
$ export EO_LIFECYCLE_DEBUG=1
$ export EINA_LOG_LEVELS=eo_lifecycle:4
$ /tmp/bogus_app
DBG:eo_lifecycle lib/eo/eo.c:2712 _eo_log_obj_init() will log all object 
allocation and free
DBG:eo_lifecycle lib/eo/eo.c:2788 _eo_log_obj_init() will NOT log class 
'Efl_Future'
DBG:eo_lifecycle lib/eo/eo.c:2788 _eo_log_obj_init() will NOT log class 
'Efl_Promise'
DBG:eo_lifecycle lib/eo/eo.c:2788 _eo_log_obj_init() will NOT log class 
'Efl_Loop_Timer'
DBG:eo_lifecycle lib/eo/eo.c:2665 _eo_log_obj_new() new obj=0x563fa35a1aa0 
obj_id=0x42cf38ef class=0x563fa35a1450 (Efl_Vpath_Core) [0.0004]
DBG:eo_lifecycle lib/eo/eo.c:2665 _eo_log_obj_new() new obj=0x563fa35af8d0 
obj_id=0x46cf38f0 class=0x563fa35aecf0 (Efl_Loop) [0.0005]
DBG:eo_lifecycle lib/eo/eo.c:2665 _eo_log_obj_new() new obj=0x563fa35d61a0 
obj_id=0x40007ecf390e class=0x563fa35d48f0 (Efl_Net_Dialer_Simple) [0.0054]
DBG:eo_lifecycle lib/eo/eo.c:2665 _eo_log_obj_new() new obj=0x563fa35d6470 
obj_id=0x400082cf390f class=0x563fa35d0d60 (Efl_Net_Dialer_Tcp) [0.0055]
DBG:eo_lifecycle lib/eo/eo.c:2665 _eo_log_obj_new() new obj=0x563fa35d75b0 
obj_id=0x400086cf3910 class=0x563fa35d66b0 (Efl_Io_Queue) [0.0056]
DBG:eo_lifecycle lib/eo/eo.c:2665 _eo_log_obj_new() new obj=0x563fa35d8f70 
obj_id=0x40008acf3911 class=0x563fa35d7860 (Efl_Io_Copier) [0.0057]
DBG:eo_lifecycle lib/eo/eo.c:2665 _eo_log_obj_new() new obj=0x563fa35df980 
obj_id=0x4000a6cf3918 class=0x563fa35d66b0 (Efl_Io_Queue) [0.0058]
DBG:eo_lifecycle lib/eo/eo.c:2665 _eo_log_obj_new() new obj=0x563fa35dfc30 
obj_id=0x4000aacf3919 class=0x563fa35d7860 (Efl_Io_Copier) [0.0058]

will efl_class_name_get() with invalid handle:

ERR:eo lib/eo/eo.c:1013 efl_class_name_get() Class (0x2029) is 
an invalid ref.
ERR:eo_lifecycle lib/eo/eo.c:1013 efl_class_name_get() 
obj_id=0x2029 was neither created or deleted 
(EO_LIFECYCLE_NO_DEBUG='Efl_Loop_Timer,Efl_Promise,Efl_Future').
DBG:eo_lifecycle lib/eo/eo.c:2688 _eo_log_obj_free() free 
obj=0x563fa35df980 obj_id=0x4000a6cf3918 class=0x563fa35d66b0 
(Efl_Io_Queue) [0.0061]
DBG:eo_lifecycle lib/eo/eo.c:2688 _eo_log_obj_free() free 
obj=0x563fa35dfc30 obj_id=0x4000aacf3919 class=0x563fa35d7860 
(Efl_Io_Copier) [0.0061]
DBG:eo_lifecycle lib/eo/eo.c:2688 _eo_log_obj_free() free 
obj=0x563fa35d75b0 obj_id=0x400086cf3910 class=0x563fa35d66b0 
(Efl_Io_Queue) [0.0061]
DBG:eo_lifecycle lib/eo/eo.c:2688 _eo_log_obj_free() free 
obj=0x563fa35d8f70 obj_id=0x40008acf3911 class=0x563fa35d7860 
(Efl_Io_Copier) [0.0061]
DBG:eo_lifecycle lib/eo/eo.c:2688 _eo_log_obj_free() free 
obj=0x563fa35d6470 obj_id=0x400082cf390f class=0x563fa35d0d60 
(Efl_Net_Dialer_Tcp) [0.0063]
DBG:eo_lifecycle lib/eo/eo.c:2688 _eo_log_obj_free() free 
obj=0x563fa35d61a0 obj_id=0x40007ecf390e class=0x563fa35d48f0 
(Efl_Net_Dialer_Simple) [0.0063]

will double free:

ERR:eo ../src/lib/eo/efl_object.eo.c:78 efl_del() EOID 0x40007ecf390e 
is not a valid object. EOID domain=0, current_domain=0, local_domain=0. EOID 
generation=2cf390e, id=1f, ref=1, super=0. Thread self=main. Available domains 
[0 1]. Maybe it has been deleted or does not belong to your thread?
ERR:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del() 
obj_id=0x40007ecf390e created obj=0x563fa35d61a0, class=0x563fa35d48f0 
(Efl_Net_Dialer_Simple) [0.0054s, 0.0009 ago]:
ERR:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del()
0x007f2c0bc6d0ea: libeo_dbg.so+0x90ea (in src/lib/eo/.libs/libeo_dbg.so 
0x7f2c0bc64000)
ERR:eo_lifecycle ../src/lib/eo/efl_object.eo.c:78 efl_del()
0x007f2c0bc6ca62: _efl_add_internal_start+0x1c2 (in 
src/lib/eo/.libs/libeo_dbg.so 0x7f2c0bc64000)
ERR:eo_lifecycle