On Mon, 5 Mar 2018 10:44:09 -0300 Gustavo Sverzut Barbieri <barbi...@gmail.com> said:
> On Sat, Mar 3, 2018 at 6:01 AM, Carsten Haitzler <ras...@rasterman.com> wrote: > > raster pushed a commit to branch master. > > > > http://git.enlightenment.org/core/efl.git/commit/?id=d80ef6d7a98e0cb3ceb995573c58d1df965639e4 > > > > commit d80ef6d7a98e0cb3ceb995573c58d1df965639e4 > > Author: Carsten Haitzler (Rasterman) <ras...@rasterman.com> > > Date: Sat Mar 3 17:15:10 2018 +0900 > > > > efl loop promises - cleare out promise data to null > > > > so there is something broken in the complect efl promise/loop promise > > that the clear of promises on loop destroy is clearing > > promises/futures that have already triggered (loop timer ones). i've > > spent enough time figuring out that it is happening. > > _efl_loop_timeout_del() simple doenst ensure the future in > > pending_futures for that promise is removed from the list. getting the > > future from the promise handle is an exercise in pain... so i'm not > > continuing with that path and will just ignore it. > > > > but for now filling the promise data with null at least means if the > > menory is re-used after free it wont see garbage freed ptrs and get > > nulls so its easier to track. > > --- > > src/lib/ecore/efl_loop.c | 11 ++++++++++- > > 1 file changed, 10 insertions(+), 1 deletion(-) > > > > diff --git a/src/lib/ecore/efl_loop.c b/src/lib/ecore/efl_loop.c > > index 0ccee1706f..b3a58f9ae9 100644 > > --- a/src/lib/ecore/efl_loop.c > > +++ b/src/lib/ecore/efl_loop.c > > @@ -488,7 +488,10 @@ static void > > _efl_loop_idle_cancel(void *data, const Eina_Promise *dead_ptr EINA_UNUSED) > > { > > Efl_Loop_Promise_Simple_Data *d = data; > > + > > ecore_idler_del(d->idler); > > + d->idler = NULL; > > + d->promise = NULL; > > efl_loop_promise_simple_data_mp_free(d); > > } > > this is strange: d comes from the mempool and all calls are protected > with "is p valid in the mempool", which should evaluate to false. > > then you're just hiding some other problem. valgrind told me that d was pointing it some recently recycled memory. so it had been freed then re-allocated again. so i was at least setting it to NULL so if freed memory was being accessed then it'd instantly crash rather than "kind of work". this was actually about trying to make it crash more instantly by ensuring we have null ptrs in freed memory here. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- 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
