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 504672 - [ffdeinterlace] crashes with height/width not multiples of 8
[ffdeinterlace] crashes with height/width not multiples of 8
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-libav
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-12-20 14:22 UTC by Tim-Philipp Müller
Modified: 2013-07-17 10:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
ffdeinterlace: reject sizes that ffmpeg will trip on (1.66 KB, patch)
2011-09-09 13:07 UTC, Vincent Penquerc'h
none Details | Review

Description Tim-Philipp Müller 2007-12-20 14:22:12 UTC
This is with gst-ffmpeg CVS:

$ gst-launch-0.10 videotestsrc ! video/x-raw-yuv,format=\(fourcc\)I420,width=700,height=412 ! ffdeinterlace ! fakesink
Caught SIGSEGV accessing address 0x17

In gdb:

Program received signal SIGSEGV, Segmentation fault.

Thread 1082132816 (LWP 24517)

  • #0 _int_free
    from /lib/libc.so.6
  • #1 free
    from /lib/libc.so.6
  • #2 gst_buffer_finalize
    at gstbuffer.c line 185
  • #3 gst_mini_object_unref
    at gstminiobject.c line 306
  • #4 gst_ffmpegdeinterlace_chain
    at gstffmpegdeinterlace.c line 188
  • #5 gst_pad_chain_unchecked
    at gstpad.c line 3503
  • #6 gst_pad_push
    at gstpad.c line 3671
  • #7 gst_base_transform_chain
    at gstbasetransform.c line 1614
  • #8 gst_pad_chain_unchecked
    at gstpad.c line 3503
  • #9 gst_pad_push
    at gstpad.c line 3671
  • #10 gst_base_src_loop
    at gstbasesrc.c line 2063
  • #11 gst_task_func
    at gsttask.c line 192
  • #12 ??
    from /usr/lib/libglib-2.0.so.0
  • #13 ??
    from /usr/lib/libglib-2.0.so.0
  • #14 start_thread
    from /lib/libpthread.so.0
  • #15 clone
    from /lib/libc.so.6
  • #16 ??

Comment 1 Edward Hervey 2007-12-23 16:58:45 UTC
basically... all hell breaks loose after the call to avpicture_deinterlace.
Comment 2 Edward Hervey 2008-01-08 17:43:00 UTC
For some reason it's writing too far (this happens when converting the last pair of lines when looking through the debug logs).

==32502== Thread 2:
==32502== Invalid write of size 4
==32502==    at 0x8589810: avpicture_deinterlace (imgconvert.c:2709)
==32502==    by 0x85270E2: gst_ffmpegdeinterlace_chain (gstffmpegdeinterlace.c:185)
==32502==    by 0x4E789D8: gst_pad_chain_unchecked (gstpad.c:3518)
==32502==    by 0x4E78FF2: gst_pad_push (gstpad.c:3686)
==32502==    by 0x7C4E659: gst_base_transform_chain (gstbasetransform.c:1614)
==32502==    by 0x4E789D8: gst_pad_chain_unchecked (gstpad.c:3518)
==32502==    by 0x4E78FF2: gst_pad_push (gstpad.c:3686)
==32502==    by 0x7C49A0A: gst_base_src_loop (gstbasesrc.c:2063)
==32502==    by 0x4E90EC8: gst_task_func (gsttask.c:192)
==32502==    by 0x615DC74: g_thread_pool_thread_proxy (gthreadpool.c:265)
==32502==    by 0x615C113: g_thread_create_proxy (gthread.c:635)
==32502==    by 0x5AED066: start_thread (pthread_create.c:297)
==32502==  Address 0x9128648 is 0 bytes after a block of size 432,600 alloc'd
==32502==    at 0x4C2101B: malloc (vg_replace_malloc.c:207)
==32502==    by 0x614205A: g_malloc (gmem.c:131)
==32502==    by 0x4E56BBE: gst_buffer_new_and_alloc (gstbuffer.c:322)
==32502==    by 0x4E78253: gst_pad_alloc_buffer_full (gstpad.c:2697)
==32502==    by 0x8527069: gst_ffmpegdeinterlace_chain (gstffmpegdeinterlace.c:174)
==32502==    by 0x4E789D8: gst_pad_chain_unchecked (gstpad.c:3518)
==32502==    by 0x4E78FF2: gst_pad_push (gstpad.c:3686)
==32502==    by 0x7C4E659: gst_base_transform_chain (gstbasetransform.c:1614)
==32502==    by 0x4E789D8: gst_pad_chain_unchecked (gstpad.c:3518)
==32502==    by 0x4E78FF2: gst_pad_push (gstpad.c:3686)
==32502==    by 0x7C49A0A: gst_base_src_loop (gstbasesrc.c:2063)
==32502==    by 0x4E90EC8: gst_task_func (gsttask.c:192)
Comment 3 Edward Hervey 2010-07-07 13:53:11 UTC
Still happens. We should just refuse caps with non-multiple-of-8 width/height.
Comment 4 Vincent Penquerc'h 2011-09-09 13:06:55 UTC
ffmpeg will use a higher aligned stride for the destination buffer, and not the smaller-aligned stride GStreamer expects (352 instead of 350 for the command line above for the subsampled plane).

It only tests for multiple of 4 for both widths and heights though. Patch attached.
Comment 5 Vincent Penquerc'h 2011-09-09 13:07:09 UTC
Created attachment 196109 [details] [review]
ffdeinterlace: reject sizes that ffmpeg will trip on

imgconvert does not support widths that aren't multiple of 8,
and will overwrite the destination.
While there, also reject heights not multiple of 4, which will
just be ignored by ffmpeg, yielding an uninitialized buffer.
Comment 6 Edward Hervey 2013-07-17 10:03:10 UTC
Works fine in git. Closing.
Comment 7 Tim-Philipp Müller 2013-07-17 10:59:26 UTC
Not sure if it doesn't just work by coincidence rather than design.

I don't see any code in gstavdeinterlace.c that makes sure video frames have sufficient strides or padding..