Fix is in, but probably needs some testing to make sure I'm not a borker. I still don't have a decent computer, unfortunately.
On Sat, Jan 5, 2013 at 12:01 PM, Tom Hacohen <[email protected]> wrote: > SPANK SPANK SPANK > > I believe I have a fix, will commit it soon. > > > > > On Sat, Jan 5, 2013 at 1:39 AM, Carsten Haitzler <[email protected]>wrote: > >> we have a fundamental problem here. >> >> evas in 1.7: >> static void >> evas_object_smart_clipped_smart_del(Evas_Object *obj) >> { >> CSO_DATA_GET_OR_RETURN(obj, cso); >> >> if (cso->clipper) >> { >> Evas_Object *clipper = cso->clipper; >> cso->clipper = NULL; >> evas_object_del(clipper); >> } >> >> _evas_object_smart_members_all_del(obj); >> >> free(cso); >> evas_object_smart_data_set(obj, NULL); >> } >> >> and in in trunk(1.8 to be): >> static void >> evas_object_smart_clipped_smart_del(Evas_Object *eo_obj) >> { >> CSO_DATA_GET_OR_RETURN(eo_obj, cso); >> >> if (cso->clipper) >> { >> Evas_Object *clipper = cso->clipper; >> cso->clipper = NULL; >> evas_object_del(clipper); >> } >> >> _evas_object_smart_members_all_del(eo_obj); >> >> evas_object_smart_data_set(eo_obj, NULL); >> } >> >> notice a KEY difference... 1.8 has no free() of cso. >> >> this means that if we add the free() we segv all over now in efl. BUT... >> if we >> dont add it .. we LEAK! because in 1.7 - applications using the smart >> clipped >> smart object were expected to malloc/calloc the cso themselves... BUT they >> expected smart_clipped to do the free() so they didnt do it. >> >> this is the now back and forth in terminology about the free of the smart >> data >> or not. in efl 1.7 we have dont need to free. in fact a free in the >> terminology >> smart causes a segv. if we DONT free tho with trunk, we leak now - in an >> unlimited way (every time we create any smart obj inheriting from >> smart_clipped). >> >> this is basically an abi break. we need a solution. and quickly >> preferably. >> basically to maintain abi and api compat, smart_clipped HAS to do the >> free(). >> that's a given. there is no choice here. so how to we make the new eo >> changes >> work with this assumption? eo could override the smart del func and >> duplicate >> its own wherever used if *IT* wants to do the free - that means basically >> copy >> & paste the small bit of code there (duplicate it), OR you create a new >> smart >> clipped class that in evas that is identical except it pushes the freeing >> back >> up to the inheritor (which is what eo expects) and that means everywhere >> eo is >> using smart clipped it needs to change to use this new >> "smart_clipped_nofree" >> class. >> >> right now i lean to making a new nofree class and then adapting all the >> eo code >> that expects to do its own freeing to use that. >> >> -- >> ------------- Codito, ergo sum - "I code, therefore I am" -------------- >> The Rasterman (Carsten Haitzler) [email protected] >> >> >> >> ------------------------------------------------------------------------------ >> 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 >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > > > > -- > Tom. > -- Tom. ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
