GNOME Bugzilla – Bug 385084
endless ghost pad pull/push activate recursion until crash
Last modified: 2007-02-20 10:16:51 UTC
Try (with valid URI): gst-launch-0.10 http://host/foo.ogg ! identity ! decodebin ! fakesink This crashes here like this: Program received signal SIGSEGV, Segmentation fault.
+ Trace 93568
Thread NaN (LWP 31870)
Easier way to reproduce: gst-launch-0.10 file:///path/to/file.ogg ! queue ! identity ! decodebin ! fakesink -v
Doesn't happen without the identity, btw so possibly basetransform's fault.
seems to be a ghostpad thing.
Seen something similar today (only similar, because the repetead activation was consecutive and not recursive like here) with a demuxer supporting pull-mode. Basically it would repeatedly try to active the demuxer if the demuxer added pads during activation, but then for some reason still returned FALSE from its activate function (then the demuxer would do the same again and it loops forever). May or may not be related, not sure.
* docs/design/part-gstghostpad.txt: * gst/gstghostpad.c: (gst_ghost_pad_class_init), (gst_ghost_pad_internal_do_activate_push), (gst_ghost_pad_internal_do_activate_pull), (gst_ghost_pad_do_activate_push), (gst_ghost_pad_do_activate_pull), (gst_ghost_pad_do_link), (gst_ghost_pad_dispose), (gst_ghost_pad_new_full), (gst_ghost_pad_set_target): Do not set the internal pad as a parent anymore so we can avoid hierarchy linking errors when the ghostpad has no parent yet. This also fixes failed activation because of unlinked internal pads, which in turn fixes the impossible case where you have to activate a pad before you can add it to a running element. Also fix the docs. * gst/gstpad.c: (pre_activate), (post_activate), (gst_pad_set_active), (gst_pad_activate_pull), (gst_pad_activate_push), (gst_pad_check_pull_range): Add some more debug info. Mark activation mode in pre_activate so that we don't try to activate in endless loops. Fixes #385084.