On Fri, 21 Aug 2015 17:16:54 +0100 Tom Hacohen <t...@osg.samsung.com> said:
> On 20/08/15 07:09, Daniel Zaoui wrote: > > The parent should never be !NULL when reaching the destructor. Imo, this > > code has not to be here. Instead, an error message should be displayed in > > the case the parent is still connected to the object. There is a bug but > > definitely the solution doesn't have to be here. I think this issue may > > happen if eo_del is never called and eo_unref is called instead. We need to > > check inside _eo_unref that the parent is NULL and display an error message. > > > > Tom, any thoughts? > > Sorry it took me so long to reply, I was busy with some urgent matters. > > I agree with Daniel here. It's exactly what I separately said on IRC. I > think it's not a bug in Eo but a bug in the application. There are two > valid cases in which an object with a parent is deleted: > 1. The parent is deleted - when this happens, the child's parent will be > NULL and thus the error case described is not relevant. > 2. eo_del() is called on the object - eo_del() clears the parent, so in > this case, the parent will be null for the destructor too. > > Thus, the only case in which the destructor will be called while the > parent is NULL is an error case, when someone unrefs an object too much > (i.e unrefs a ref it doesn't hold). This case is a user error and should > result in an error message. Not a cleanup like this patch does. I think > it's wrong and should be removed, and an error message should be added, > or in other words, "what daniel said". bvut that was not the issue. the issue was that unref was called not del. that's fine. it should be. the parent never removed the child from its list. thus when walking children to unparent them (thus unref them) there were objects in the child list that had been destroyed already, thus getting the eo scope data for that child failed (which it should not have) which resulted in the crash. the scope get should never have failed at all as all children should have been valid. what i did was put the "remove myself from my parent" in the destructor. it had to be done one way or the other. it could be in eo_unref (but then it'd only have to unparent if refcount is 1 as opposed to del that always unparents). it's functionally the same. just which func does the code go into. well ok there is a diff. is the child still a child of the parent when destructor is called. no matter what child should NOT be a child once destructor is finished. should it ALREADY cease to be a child BEFORE destructor is called? should a destructor be able to know the objects (former) parent? currently with eo_del it cannot and with eo_unref it can. this is inconsistent atm. but perhaps the eo_del code is wrong? a child should remain a child UNTIL destructor has finished? you can't "do things" to your parent then during destruction unless this is the case. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
