Hi, I'm looking into this. Can you explain how you got this backtrace? That would be great.

"src/modules/emotion/gstreamer1/emotion_gstreamer.c"

static void
em_file_close(void *video)
{
   Emotion_Gstreamer *ev = video;
   Eina_List *l;

   ev->shutdown = EINA_TRUE;

   if (ev->threads)
     {
        Ecore_Thread *t;

        EINA_LIST_FOREACH(ev->threads, l, t)
          {
             ecore_thread_cancel(t);
          }

      // XXX: Should wait for threads to finish unblocking actions ???
     }

   if (ev->pipeline)
     {
       if (ev->audio_buffer_probe)
         {
            gst_pad_remove_probe(ev->audio_buffer_probe_pad, ev->audio_buffer_probe);
            gst_object_unref(ev->audio_buffer_probe_pad);
            ev->audio_buffer_probe_pad = NULL;
            ev->audio_buffer_probe = 0;
         }

       gst_element_set_state(ev->pipeline, GST_STATE_NULL);
       g_object_set(G_OBJECT(ev->vsink), "emotion-object", NULL, NULL);
       gst_object_unref(ev->pipeline);

       ev->pipeline = NULL;
       ev->vsink = NULL;
     }

   if (ev->metadata)
     {
        _free_metadata(ev->metadata);
        ev->metadata = NULL;
     }

   ev->ready = EINA_FALSE;
}

AFAIU two things can cause this:

a) if _set_state is called from a streaming thread (this is bad)
b) If some element does not unblock it's streaming thread.

So, I wonder should we be waiting for the threads to cancel?

See XXX in above code.

gst_element_set_state(ev->pipeline, GST_STATE_NULL) can block in the two above scenarios.

@segfaultxavi you said you had some experience with gstreamer. Adding you into this one!

Yeah, how can I reproduce the issue?

I'm unable to reproduce. I would think with emotion_test cases and using a small test file.

I've just done a little work from the backtrace above and based on that.

Other than this, I'm afraid I can't give you a sure means of achieving the above backtrace or similar yourself.

This is a very rare corner case which can occur on any emotion object deletion when a video is playing. The OP backtrace is in the main thread, as evidenced by the object deletion being present.

I have started and closed emotion_test about 10 times and never got a deadlock. I have done the same thing with rage and never got a deadlock, but it segfaults on exit every time (can provide backtrace, but this is probably a different issue).

@zmike How often can you trigger this deadlock?

As I said, it's very rare. I can only recall seeing it once or twice at most--it's likely not something that can be actively debugged and should instead be theoretically debugged.

So, I'm no gst guru, but is it possible in some situations those threads won't be finished after the cancel and gst_element_set_state(ev->pipeline, GST_STATE_NULL); is blocking if that sometimes happens?

gst_element_set_state() is blocking because there's some other thread blocked on a GStreamer call, probably a callback into EFl code. If we could get a backtrace of ALL threads (thread apply all bt in gdb) it should be fairly easy to find out where.

Otherwise, look at all EFl callbacks registered to GStreamer, see if they have suspicious locks, and if nothing jumps to you, add the classic lock debug output ("about to lock", "locked", "lock released") to all locks and pray :)

I no longer have the process available for debugging. Destroying any emotion object which is currently playing should have a chance to trigger this, though I'm not optimistic that even catching it would yield much in the way of information.

One last thing, @zmike, do you remember the type of media you were playing? Container, codecs... GStreamer behaves differently depending on these.

Not 100% sure, but I would guess it was the file from T6319 since it's on the desktop of my test machine. Based on the number of stack frames, this probably occurred when destroying a tooltip in Enlightenment, though I don't think that's especially relevant.

Also I'm not sure this is something that we should really be spending a lot of time on right now. It's definitely not a release-blocking issue.

Then you should lower its priority 😛

An issue's priority is not equal to its ability to block a release. It seems like every existing issue was tagged with the 1.21 milestone, and I've been going through and removing it on a lot of tickets...