Page MenuHomePhabricator

Strange a call of animator
Closed, ResolvedPublic

Description

When trigger a interrupt event using Ctrl + C,
It firstly cleans up canvas but after it calls animator callback as well.
Obviously, this sequence is insane. when interrupt event is triggered and handled by ecore, the animator callback shouldn't be called.
Or at least, canvas should be freed after animator call.

You can test this using below example.
efl/src/examples/evas/evas_vg_batman.
and press Ctrl + C
It often happens.

Hermet created this task.Jun 12 2018, 3:36 AM
Hermet triaged this task as High priority.
Hermet moved this task from Backlog to mainloop on the efl board.
Hermet moved this task from mainloop to Backlog on the efl board.
Hermet edited projects, added efl: main loop; removed efl.Jun 12 2018, 3:38 AM

hmm... maybe this helps ...?

7156== Invalid read of size 8

7156== at 0x557FB3E: ecore_animator_del (ecore_anim.c:840)

7156== by 0x401390: _on_delete(_Ecore_Evas*) (test.c:43)

7156== by 0xD3A50F8: _ecore_evas_x_event_window_delete_request (ecore_evas_x.c:1746)

7156== by 0x558A0D3: _ecore_event_message_handler_efl_loop_message_handler_message_call (ecore_event_message_handler.c:359)

7156== by 0x5590D5B: efl_loop_message_handler_message_call (in /usr/local/lib/libecore.so.1.20.99)

7156== by 0x558CF8C: _efl_loop_message_process (efl_loop.c:633)

7156== by 0x558BC04: efl_loop_message_process (in /usr/local/lib/libecore.so.1.20.99)

7156== by 0x5586948: _ecore_main_loop_iterate_internal (ecore_main.c:2432)

7156== by 0x558720C: _ecore_main_loop_begin (ecore_main.c:1175)

7156== by 0x558CEB8: _efl_loop_begin (efl_loop.c:83)

7156== by 0x558BEA4: efl_loop_begin (in /usr/local/lib/libecore.so.1.20.99)

7156== by 0x55872D6: ecore_main_loop_begin (ecore_main.c:1248)

7156== Address 0xb508e90 is 32 bytes inside a block of size 80 free'd

7156== at 0x4C2EDEB: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)

7156== by 0x557F877: _ecore_animator_flush (ecore_anim.c:1015)

7156== by 0x557F9BA: _do_tick (ecore_anim.c:513)

7156== by 0x557FB0D: _timer_tick_notify (ecore_anim.c:370)

7156== by 0x55B2968: _ecore_notify_handler (ecore_thread.c:276)

7156== by 0x557D74F: _ecore_main_call_flush (ecore.c:1087)

7156== by 0x55AFFB5: _ecore_pipe_handler_call (ecore_pipe.c:607)

7156== by 0x55AFFB5: _ecore_pipe_read (ecore_pipe.c:730)

7156== by 0x55868BC: _ecore_call_fd_cb (ecore_private.h:492)

7156== by 0x55868BC: _ecore_main_fd_handlers_call (ecore_main.c:2054)

7156== by 0x55868BC: _ecore_main_loop_iterate_internal (ecore_main.c:2427)

7156== by 0x558720C: _ecore_main_loop_begin (ecore_main.c:1175)

7156== by 0x558CEB8: _efl_loop_begin (efl_loop.c:83)

7156== by 0x558BEA4: efl_loop_begin (in /usr/local/lib/libecore.so.1.20.99)

7156== by 0x55872D6: ecore_main_loop_begin (ecore_main.c:1248)

7156== Block was alloc'd at

7156== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)

7156== by 0x557E2F2: _ecore_animator_add (ecore_anim.c:535)

7156== by 0x557EE52: ecore_animator_timeline_add (ecore_anim.c:563)

7156== by 0x4018A2: main (test.c:128)

zmike added a comment.Jun 22 2018, 7:23 AM

Okay, so there are a number of issues here:

  • Example code tries to delete animator after animator will already definitely be destroyed
    • animators are destroyed internally any time they return false
  • I think the event queue is flushed after the signal handler is called, which is a normal thing, and this will trigger another animator callback

So overall I think it's just the example code which should be changed to not attempt to destroy the animator. Also animator API seems bad since it allows this to happen...

Trying to understand the bug here...

animators have never been tied to a canvas, so the animator continuing to tick after the canvas is destroyed is unsurprising?

Deleting the animator from the canvas delete callback seems like it would always have been a race.

I think what needs to happen here is _animator() needs to be a NOP after the canvas is deleted?

Hermet added a commit: Restricted Diffusion Commit.Aug 20 2018, 1:03 PM