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
Ondrej
--
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