random segfault in extended playout example

otopolsky topolsky at maindata.sk
Fri Oct 23 07:55:35 PDT 2015

Hi thanks for the hint.

There is only one unref of element in the code (the others are just pads or
caps etc) and that is inside playout_remove_pad:

  mixer = gst_pad_get_parent_element (sinkpad);
  gst_element_release_request_pad (mixer, sinkpad);
  gst_object_unref (sinkpad);
  gst_object_unref (mixer);

This playout_remove_pad can be called either from main context g_timeout_add
(500, .. ) or directly from callback function depending on which pad goes
eos first - video/audio. There is also some suspicious FIXME comment in
original example(before playout_item_pad_probe_event which is calling
playout_remove_pad) :
* FIXME: Add locking. Both pads could go EOS at the exact same time. */

My guess is that in some scenario playout_remove_pad is called twice from
different threads ending in some race condition.

I think this can also happen in original code, but I dont think anyone will
trigger it as there is no looping capabilities, the app ends after playing
the videos..

Possible solutions:

1, add mutex around ref/unref of mixer in playout_remove_pad
2, get the pointer directly as the element is alive until end of app.

What do you think of this?

Thanks, all the best


View this message in context: http://gstreamer-devel.966125.n4.nabble.com/random-segfault-in-extended-playout-example-tp4674225p4674238.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.

More information about the gstreamer-devel mailing list