After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 686365 - pad: segfault querying pad caps
pad: segfault querying pad caps
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
1.x
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-10-18 11:19 UTC by Andoni Morales
Modified: 2012-10-18 17:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Working test case (2.51 KB, text/x-csrc)
2012-10-18 12:24 UTC, Andoni Morales
Details

Description Andoni Morales 2012-10-18 11:19:31 UTC
I can trigger a segfault in gst_pad_query_caps with the following use case:
  * pipeline appsrc nun-buffers=1 ! decodebin
  * connect to decodebin's "new-decoded-pad"
  * push one buffer to appsrc containing 5 seconds of H264 muxed in a mpegts stream, appsrc sends an eos after this buffer is pushed because of num-buffers=1
  * query caps in for the new pad in new_decoded_caps_cb callback

Program received signal SIGSEGV, Segmentation fault.
[Cambiando a Thread 0x7fffe3fff700 (LWP 16832)]
0x00007ffff757ba8c in g_datalist_id_get_data () from /home/andoni/cerbero/dist/linux_x86_64/lib/libglib-2.0.so.0
(gdb) bt
  • #0 g_datalist_id_get_data
    from /home/andoni/cerbero/dist/linux_x86_64/lib/libglib-2.0.so.0
  • #1 g_object_notify_queue_freeze
    from /home/andoni/cerbero/dist/linux_x86_64/lib/libgobject-2.0.so.0
  • #2 g_object_notify_by_spec_internal
    from /home/andoni/cerbero/dist/linux_x86_64/lib/libgobject-2.0.so.0
  • #3 g_object_notify_by_pspec
    from /home/andoni/cerbero/dist/linux_x86_64/lib/libgobject-2.0.so.0
  • #4 gst_pad_store_sticky_event
    at gstpad.c line 4429
  • #5 gst_pad_push_event
    at gstpad.c line 4626
  • #6 event_forward_func
    at gstpad.c line 2719
  • #7 gst_pad_forward
    at gstpad.c line 2673
  • #8 gst_pad_event_default
    at gstpad.c line 2770
  • #9 gst_pad_send_event_unchecked
    at gstpad.c line 4821
  • #10 gst_pad_push_event_unchecked
    at gstpad.c line 4514
  • #11 push_sticky
    at gstpad.c line 3285
  • #12 events_foreach
    at gstpad.c line 514
  • #13 check_sticky
    at gstpad.c line 3333
  • #14 gst_pad_push_event
    at gstpad.c line 4635
  • #15 gst_single_queue_push_one
    at gstmultiqueue.c line 1080
  • #16 gst_multi_queue_loop
    at gstmultiqueue.c line 1303
  • #17 gst_task_func
    at gsttask.c line 316
  • #18 g_thread_pool_thread_proxy
    from /home/andoni/cerbero/dist/linux_x86_64/lib/libglib-2.0.so.0
  • #19 g_thread_proxy
    from /home/andoni/cerbero/dist/linux_x86_64/lib/libglib-2.0.so.0
  • #20 start_thread
    at pthread_create.c line 308
  • #21 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 112
  • #22 ??
  • #4 gst_pad_store_sticky_event
    at gstpad.c line 4429
4424	    switch (GST_EVENT_TYPE (event)) {
4425	      case GST_EVENT_CAPS:
4426	        GST_OBJECT_UNLOCK (pad);
4427	
4428	        GST_DEBUG_OBJECT (pad, "notify caps");
4429	        g_object_notify_by_pspec ((GObject *) pad, pspec_caps);
4430	
4431	        GST_OBJECT_LOCK (pad);
4432	        break;
4433	      default:
(gdb) p *pad
$1 = {object = {object = {g_type_instance = {g_class = 0x7fffed8d5c00}, ref_count = 6, qdata = 0x7254c4}, lock = {p = 0x7fffe405b060, i = {3825578080, 32767}}, 
    name = 0x7fffdc001a70 "src_0", parent = 0x7fffed978090, flags = 29952, control_bindings = 0x0, control_rate = 100000000, last_sync = 18446744073709551615, 
    _gst_reserved = 0x0}, element_private = 0x0, padtemplate = 0x7fffe401a420, direction = GST_PAD_SRC, stream_rec_lock = {p = 0x7fffe4056490, i = {0, 0}}, task = 0x0, 
  block_cond = {p = 0x7fffe4059950, i = {0, 0}}, probes = {seq_id = 2, hook_size = 72, is_setup = 1, hooks = 0x7fffe402b2d0, dummy3 = 0x0, 
    finalize_hook = 0x7ffff7589824 <default_finalize_hook>, dummy = {0x0, 0x0}}, mode = GST_PAD_MODE_PUSH, activatefunc = 0x7ffff7b479e0 <gst_pad_activate_default>, 
  activatedata = 0x0, activatenotify = 0, activatemodefunc = 0x7ffff7b35620 <gst_ghost_pad_activate_mode_default>, activatemodedata = 0x0, activatemodenotify = 0, peer = 0x0, 
  linkfunc = 0, linkdata = 0x0, linknotify = 0, unlinkfunc = 0, unlinkdata = 0x0, unlinknotify = 0, chainfunc = 0, chaindata = 0x0, chainnotify = 0, 
  chainlistfunc = 0x7ffff7b432d0 <gst_pad_chain_list_default>, chainlistdata = 0x0, chainlistnotify = 0, getrangefunc = 0x7ffff7b350b0 <gst_proxy_pad_getrange_default>, 
  getrangedata = 0x0, getrangenotify = 0, eventfunc = 0x7ffff7b48650 <gst_pad_event_default>, eventdata = 0x0, eventnotify = 0, offset = 0, 
  queryfunc = 0x7ffff7b47fc0 <gst_pad_query_default>, querydata = 0x0, querynotify = 0, iterintlinkfunc = 0x7ffff7b35370 <gst_proxy_pad_iterate_internal_links_default>, 
  iterintlinkdata = 0x0, iterintlinknotify = 0, num_probes = 1, num_blocked = 0, priv = 0x7fffe401c640, _gst_reserved = {0x0, 0x0, 0x0, 0x0}}
(gdb) p pspec_caps
$2 = (GParamSpec *) 0x6198f0
(gdb) p *pspec_caps
$3 = {g_type_instance = {g_class = 0x6131a0}, name = 0x7ffff7b9fec9 "caps", flags = 225, value_type = 6360208, owner_type = 6360704, _nick = 0x7ffff7b96ec7 "Caps", 
  _blurb = 0x7ffff7b9faed "The capabilities of the pad", qdata = 0x0, ref_count = 2, param_id = 1}
(gdb)
Comment 1 Andoni Morales 2012-10-18 12:24:23 UTC
Created attachment 226734 [details]
Working test case

The bug is triggered in this condition:
https://github.com/ylatuya/gst-plugins-bad/blob/master/gst-libs/gst/baseadaptive/gstbaseadaptivesink.c#L1315
where gst_base_adaptive_sink_parse_stream is called from the element's chain function.

The test case simulates it, but the bug is not triggered there.
Comment 2 Andoni Morales 2012-10-18 12:29:19 UTC
(In reply to comment #0)
> I can trigger a segfault in gst_pad_query_caps with the following use case:
>   * pipeline appsrc nun-buffers=1 ! decodebin
>   * connect to decodebin's "new-decoded-pad"

I am using pad_added and not the old new-decoded-pad
Comment 3 Andoni Morales 2012-10-18 17:26:09 UTC
My bad, I was using the signature of the old new-decoded-pad in the callback instead of the pad_added one :)