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 743909 - videobox, videocrop: crash with bottom=-214748364
videobox, videocrop: crash with bottom=-214748364
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
unspecified
Other Linux
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 743910 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-02-03 06:08 UTC by Vineeth
Modified: 2018-05-06 12:16 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Vineeth 2015-02-03 06:08:33 UTC
When the top/left/right/bottom values are anything more than video width/height, then the pipeline crashes.
Sample pipeline is as follows.

gst-launch-1.0 videotestsrc num-buffers=20 ! videobox bottom=-214748364 ! videoconvert ! autovideosink


The values should be handled properly as per video height/width
Comment 1 Tim-Philipp Müller 2015-03-28 15:31:59 UTC
Doesn't crash for me, but errors out with not-negotiated flow, as expected, or a bufferpool configuration error.

Could you provide a stack trace of the crash please?
Comment 2 Vineeth 2015-04-23 06:21:13 UTC
Hi Tim,
     I was able to reproduce the issue with specific values of the parameters. When i give very high values it gives bufferpool configuration error, after some recent changes in bufferpool i guess.

     But when give in specific range it crashes with SIGSEGV. This is the parameters i used

Starting program: /home/vineeth/gst/master/gstreamer/tools/.libs/lt-gst-launch-1.0 videotestsrc num-buffers=20 \! videobox bottom=1677722 \! videoconvert \! autovideosink

    and below is the stack trace.
  • #0 video_orc_pack_RGBA
    at tmp-orc.c line 4673
  • #1 convert_hline_generic
    at videotestsrc.c line 1202
  • #2 videotestsrc_convert_tmpline
    at videotestsrc.c line 275
  • #3 gst_video_test_src_smpte
    at videotestsrc.c line 423
  • #4 gst_video_test_src_fill
    at gstvideotestsrc.c line 955
  • #5 gst_base_src_default_create
    at gstbasesrc.c line 1482
  • #6 gst_base_src_get_range
    at gstbasesrc.c line 2461
  • #7 gst_base_src_loop
    at gstbasesrc.c line 2737
  • #8 gst_task_func
    at gsttask.c line 331
  • #9 ??
    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  • #10 ??
    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  • #11 start_thread
    at pthread_create.c line 312
  • #12 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 111


    Funny part is, it crashes when bottom=1677722, but does not when it is bottom=1677721. So there is some logic which needs to be checked.
    The same crash happens in videocrop as well.

Regards,
Vineeth
Comment 3 Tim-Philipp Müller 2015-04-23 19:03:28 UTC
And what videosink is used for your here, and what format is negotiated?

Could you add -v to gst-launch-1.0 and paste the output of that?
Comment 4 Tim-Philipp Müller 2015-04-23 19:15:57 UTC
*** Bug 743910 has been marked as a duplicate of this bug. ***
Comment 5 Vineeth 2015-04-24 00:03:31 UTC
Hi Tim,


It crashes with both ximagesink and glimagesink.


i have pasted the output of -v to http://ur1.ca/k8f9x
Comment 6 Tim-Philipp Müller 2015-04-24 11:57:05 UTC
Thanks, I can reproduce it with ximagesink.
Comment 7 Tim-Philipp Müller 2015-04-24 13:05:44 UTC
This happens just after y*stride goes above 0x80000000 for what it's worth. So perhaps a signed int is used somewhere for an offset?
Comment 8 Tim-Philipp Müller 2016-01-09 20:01:01 UTC
Does this still happen with git master? I don't get any crashes, but the pipeline errors out with all sinks I tried.
Comment 9 Vineeth 2016-01-25 05:58:44 UTC
This still happens.. But not with the values mentioned above..

Tested for both videobox and videocrop for "bottom=214748364".



Starting program: /home/vineethtm/gst/master/gstreamer/tools/.libs/lt-gst-launch-1.0 videotestsrc num-buffers=20 \! videobox bottom=214748364 \! videoconvert \! autovideosink
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Setting pipeline to PAUSED ...
[New Thread 0xb7400b40 (LWP 30237)]
[New Thread 0xb69ffb40 (LWP 30238)]
Pipeline is PREROLLING ...
[New Thread 0xb61feb40 (LWP 30239)]

Program received signal SIGSEGV, Segmentation fault.

Thread 3063937856 (LWP 30238)

  • #0 video_orc_pack_YUY2
    at tmp-orc.c line 2031
  • #1 pack_YUY2
    at video-format.c line 209
  • #2 convert_hline_generic
    at videotestsrc.c line 1199
  • #3 videotestsrc_convert_tmpline
    at videotestsrc.c line 275
  • #4 gst_video_test_src_smpte
    at videotestsrc.c line 352
  • #5 gst_video_test_src_fill
    at gstvideotestsrc.c line 1022
  • #6 gst_push_src_fill
    at gstpushsrc.c line 167
  • #7 gst_base_src_default_create
    at gstbasesrc.c line 1487
  • #8 gst_push_src_create
    at gstpushsrc.c line 132
  • #9 gst_base_src_get_range
    at gstbasesrc.c line 2460
  • #10 gst_base_src_loop
    at gstbasesrc.c line 2736
  • #11 gst_task_func
    at gsttask.c line 331
  • #12 default_func
    at gsttaskpool.c line 68
  • #13 ??
    from /lib/i386-linux-gnu/libglib-2.0.so.0
  • #14 ??
    from /lib/i386-linux-gnu/libglib-2.0.so.0
  • #15 start_thread
    at pthread_create.c line 312
  • #16 clone
    at ../sysdeps/unix/sysv/linux/i386/clone.S line 129





should we just check if the crop value exceeds the video dimensions and just ignore whichever value is higher than the dimensions?
Comment 10 Sebastian Dröge (slomo) 2016-01-25 17:30:34 UTC
That would make sense, yes. And maybe also checking why exactly it crashes here, it shouldn't crash (and should already check the boundaries), but maybe there's an overflow happening somewhere.
Comment 11 Vineeth 2016-02-17 06:50:48 UTC
The problem here seems to be that of videotestsrc not being able to handle huge resolution.

A simple pipeline like the below also crashes
libtool --mode=execute gdb --args ../gstreamer/tools/gst-launch-1.0  videotestsrc num-buffers=1 ! video/x-raw,height=21474813,width=320 ! fakesink

but it is not showing any backtrace

Starting program: /home/vineethtm/gst/master/gstreamer/tools/.libs/lt-gst-launch-1.0 videotestsrc num-buffers=1 \! video/x-raw,height=21474813,width=320 \! fakesink
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Setting pipeline to PAUSED ...
[New Thread 0xb75b1b40 (LWP 19240)]
Pipeline is PREROLLING ...
[New Thread 0xb6bffb40 (LWP 19241)]

Program received signal SIGSEGV, Segmentation fault.

Thread 3076201280 (LWP 19240)

  • #0 ??
  • #1 ??



for some higher values i get
(gst-launch-1.0:19078): GLib-ERROR **: /build/buildd/glib2.0-2.40.2/./glib/gmem.c:103: failed to allocate 1707695435 bytes

Program received signal SIGTRAP, Trace/breakpoint trap.
which is again not that much a problem due to memory limitations i guess...
Comment 12 Sebastian Dröge (slomo) 2016-02-17 08:55:36 UTC
This just fails here with a proper error:

> gst-launch-1.0 videotestsrc num-buffers=1 ! video/x-raw,height=21474813,width=320 ! fakesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0: Failed to configure the buffer pool
Additional debug info:
gstbasesrc.c(3116): gst_base_src_decide_allocation_default (): /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0:
Configuration is most likely invalid, please report this issue.
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...



Please try to get a backtrace of the error that happens for you.
Comment 13 Sebastian Dröge (slomo) 2016-02-17 08:56:26 UTC
Also the one with videocrop fails the same way, without a crash.
Comment 14 Vivia Nikolaidou 2018-05-06 12:16:41 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment.
Thanks!