Bug 385623 – [quarktv] crash when plugged dynamically into a pipeline

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 385623 - [quarktv] crash when plugged dynamically into a pipeline


Summary:	[quarktv] crash when plugged dynamically into a pipeline


Status:	RESOLVED FIXED

Product:	GStreamer
Classification:	Platform
Component:	gst-plugins-good
Version:	0.10.x
Hardware:	Other Linux

Importance:	Normal normal
Target Milestone:	0.10.5
Assigned To:	GStreamer Maintainers
QA Contact:	GStreamer Maintainers

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2006-12-13 21:33 UTC by Adam Lofts
Modified:	2006-12-14 19:21 UTC

See Also:
GNOME target:	---
GNOME version:	---

Attachments
GST_DEBUG=3 log of crash (147.73 KB, text/x-log) 2006-12-13 21:34 UTC, Adam Lofts	Details

Description Adam Lofts 2006-12-13 21:33:38 UTC

I am getting a crash in the quarktv element however since I am not 100% that my method is correct I describe it below:

Given a pipeline in PLAYING state:

v4lsrc ! ffmpegcolorspace ! xvimagesink

I block the v4lsrc src pad unlink with the csp. Then I add to the pipeline a bin containing [ ffmpegcolorspace ! quarktv ] and link the blocked src pad to a ghost pad on the bin, the bin src pad to the csp and then unblock the blocked pad.

For most of the *tv filters this always works (i.e. never any crash). With the quarktv I sometimes get a crash:

Program received signal SIGSEGV, Segmentation fault.

+ Trace 93951

Thread NaN (LWP 24906)

#0 gst_quarktv_get_type
from /usr/lib/gstreamer-0.10/libgsteffectv.so
#1 gst_quarktv_get_type
from /usr/lib/gstreamer-0.10/libgsteffectv.so
#2 gst_base_transform_get_type
from /usr/lib/libgstbase-0.10.so.0
#3 gst_base_transform_get_type
from /usr/lib/libgstbase-0.10.so.0
#4 gst_pad_set_caps
from /usr/lib/libgstreamer-0.10.so.0
#5 gst_pad_alloc_buffer
from /usr/lib/libgstreamer-0.10.so.0
#6 gst_pad_push
from /usr/lib/libgstreamer-0.10.so.0
#7 gst_base_transform_get_type
from /usr/lib/libgstbase-0.10.so.0
#8 gst_pad_alloc_buffer
from /usr/lib/libgstreamer-0.10.so.0
#9 gst_pad_push
from /usr/lib/libgstreamer-0.10.so.0
#10 _gst_format_initialize
from /usr/lib/libgstreamer-0.10.so.0
#11 gst_pad_alloc_buffer
from /usr/lib/libgstreamer-0.10.so.0
#12 gst_pad_push
from /usr/lib/libgstreamer-0.10.so.0
#13 gst_base_src_get_type
from /usr/lib/libgstbase-0.10.so.0
#14 gst_task_set_lock
from /usr/lib/libgstreamer-0.10.so.0
#15 g_thread_pool_push
from /usr/lib/libglib-2.0.so.0
#16 g_thread_create_full
from /usr/lib/libglib-2.0.so.0
#17 start_thread
from /lib/tls/i686/cmov/libpthread.so.0
#18 clone
from /lib/tls/i686/cmov/libc.so.6

Comment 1 Adam Lofts 2006-12-13 21:34:32 UTC

Created attachment 78318 [details]
GST_DEBUG=3 log of crash

Comment 2 Tim-Philipp Müller 2006-12-14 14:30:50 UTC

Are you setting the effects bin to PLAYING state before you put it into the pipeline (or before you unblock the pad)?

Could you try with -good CVS to see if it's been fixed?

If it hasn't been fixed or you can't try CVS, could you please either

 - provide a small test program that demonstrates the bug, or

 - provide a stack trace with debugging symbols (your distro might
   have -dbg packages for gstreamer, as ubuntu does for example)?

Comment 3 Adam Lofts 2006-12-14 16:52:21 UTC

Hi Tim,

> Are you setting the effects bin to PLAYING state before you put it into the pipeline (or before you unblock the pad)?

After fixing this I cannot reproduce the crash. Thank you very much - a very good guess.

If a stack trace would be useful anyway (i.e. if the old behavior is classed as a bug) I can provide one, just ask.

Thanks again,
Adam

Comment 4 Tim-Philipp Müller 2006-12-14 17:39:18 UTC

> If a stack trace would be useful anyway (i.e. if the old behavior is classed as
> a bug) I can provide one, just ask.

It should never crash, no matter what.

If you can provide one, a stack trace with debugging symbols would still be very useful, that way we can make sure my recent commit does in fact fix the issue.

Comment 5 Adam Lofts 2006-12-14 19:03:42 UTC

Here is the trace with debug symbols installed.

+ Trace 94192

#0 gst_quarktv_planetable_clear
at gstquark.c line 201
#1 gst_quarktv_set_caps
at gstquark.c line 113
#2 gst_base_transform_configure_caps
at gstbasetransform.c line 625
#3 gst_base_transform_setcaps
at gstbasetransform.c line 803
#4 gst_pad_set_caps
at gstpad.c line 2328
#5 gst_pad_chain_unchecked
at gstpad.c line 2387
#6 gst_pad_push
at gstpad.c line 3578
#7 gst_base_transform_chain
at gstbasetransform.c line 1548
#8 gst_pad_chain_unchecked
at gstpad.c line 3412
#9 gst_pad_push
at gstpad.c line 3578
#10 gst_proxy_pad_do_chain
at gstghostpad.c line 189
#11 gst_pad_chain_unchecked
at gstpad.c line 3412
#12 gst_pad_push
at gstpad.c line 3578
#13 gst_proxy_pad_do_chain
at gstghostpad.c line 189
#14 gst_pad_chain_unchecked
at gstpad.c line 3412
#15 gst_pad_push
at gstpad.c line 3578
#16 gst_base_transform_chain
at gstbasetransform.c line 1548
#17 gst_pad_chain_unchecked
at gstpad.c line 3412
#18 gst_pad_push
at gstpad.c line 3578
#19 gst_base_transform_chain
at gstbasetransform.c line 1548
#20 gst_pad_chain_unchecked
at gstpad.c line 3412
#21 gst_pad_push
at gstpad.c line 3578
#22 gst_base_src_loop
at gstbasesrc.c line 1574
#23 gst_task_func
at gsttask.c line 192
#24 g_thread_pool_push
from /usr/lib/libglib-2.0.so.0
#25 g_thread_create_full
from /usr/lib/libglib-2.0.so.0
#26 start_thread
from /lib/tls/i686/cmov/libpthread.so.0
#27 clone
from /lib/tls/i686/cmov/libc.so.6

Comment 6 Tim-Philipp Müller 2006-12-14 19:21:23 UTC

Thanks a lot, that confirms it is in fact the same thing that I fixed:

 2006-12-14  Tim-Philipp Müller  <tim at centricular dot net>

        * gst/effectv/gstquark.c: (gst_quarktv_transform),
        (gst_quarktv_planetable_clear):
          Add some NULL pointer checks (possibly related to #385623).