Details
- Reviewers
zmike Hermet - Maniphest Tasks
- T7030: efl internals pass null objects to functions which should not be passed null
Diff Detail
- Repository
- rEFL core/efl
- Branch
- master
- Lint
Lint OK - Unit
No Unit Test Coverage - Build Status
Buildable 6952
This is another case where the object is being destroyed and is still trying to make calls during the destructor (smart object invalidate triggers smart group delete, destroying all subobjects for elm widgets). The object is not technically invalidated here--though it's about to be.
@bu5hm4n it would be really useful here if we could somehow get the is_invalidating flag from the eo object. This was removed from the return of efl_invalidated_get in D6223, but I'm not sure if that was correct. It seems like potentially the cases which were solved by that patch should have been solved in a different way since I think the more common use of the API would be detecting things like this, where the object is currently invalidating but the flag is not yet set...
Well, i would say lets have a discussion on that.
@zmike maybe its the best to just get the is_invalidting as a property from the eo object?
If we go back to have is_invalidating in the getter, then we need to rewrite all reparent helpers, as they are effectivily not working with this. It also feels wrong in terms of the documentation of the API, as the API clearly states that a object is invalidated when the parent is NULL.
A think i still dont understand, what is the case where you need to know that you are currently in the invalidating routine ?
We can't accept this situation. resize_obj must be valid if obj were still active. It a failure case of synchronousing both 2 objects. We must deep look and fix root cause.
The issue here is that the table is in the process of being invalidated, but the invalidated flag is not yet set. The smart object invalidate implementation invokes destroy before completing, meaning that its children will be destroyed before the parent object is ever invalidated. A number of elm widgets trigger an automatic sizing_eval whenever a subobject is destroyed, meaning that this case will occur for each child object when such a widget is deleted.
The parent widget should be able to check whether it is in the process of invalidating when a subobject is destroyed so that these sizing_eval calls can be avoided.