Page MenuHomePhabricator

examples/evas: do not attempt to free animator on window delete

Authored by zmike on Jun 29 2018, 1:59 PM.



animators are implicitly destroyed for this case, and attempting to
manually destroy them just results in an error/failure and invalid reads
since this is a poorly designed api which can internally destroy itself

fix T7000

Diff Detail

rEFL core/efl
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.
zmike created this revision.Jun 29 2018, 1:59 PM
zmike requested review of this revision.Jun 29 2018, 1:59 PM
Hermet added a comment.Jul 2 2018, 3:17 AM

But, this can not fix T7000 issue if we SIGINT by Ctrl+C, Animation will be corrupted anyhow.

Hermet requested changes to this revision.Jul 2 2018, 4:19 AM

We can remove this but i don't think this is the fundamental solution. Obviously, the behavior has been changed that breaks the compatibility.

This revision now requires changes to proceed.Jul 2 2018, 4:19 AM
zmike added a comment.Jul 2 2018, 4:25 AM

Is this actually a behavior change though? I guess I would have to go much further back in EFL to verify...

zmike edited subscribers, added: segfaultxavi; removed: committers.

animator lifetime

I can't do anything about this for at least today because I don't have real internet and thus cannot access some things.

My thought is this: did canceling an animator at any point in the past not immediately destroy the animator? For example, if an animator callback returned false, did it destroy the animator object?

I think for all callback mechanisms (animator, timer, event handler, fd handler), returning false destroyed the object. It may not have been destroyed immediately on return (ie. it may have finished the current main loop iteration), but it was certainly destroyed before the user could destroy it in a shutdown callback, wasn't it?

This requires some testing with very old efl revisions, because I think this example is not valid API usage.

animator callback

What is the expectation here? That upon receiving a signal there is no frame after that point and no rendering occurs? We can make that change obviously, but I think we should clearly define (and possibly document?) exactly what the expectation is when a signal is received by an EFL application. Adding @segfaultxavi for docs.


Also, I think we should not be adding the 'committers' group to tickets unless it's critical that every single person reads and takes action on the ticket. We should attempt to cut down on mailing everyone where possible since all actions on patch review already email everyone.

zmike requested review of this revision.Jul 13 2018, 11:00 AM

Okay, so I went all the way back to 1.7 and the behavior is exactly the same here. It's just a bad object implementation.

This revision was not accepted when it landed; it landed in state Needs Review.Jul 17 2018, 11:31 PM
This revision was automatically updated to reflect the committed changes.