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 745054 - glimagesink: Segfault with webm/vp8 files that has odd height
glimagesink: Segfault with webm/vp8 files that has odd height
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal critical
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-02-23 21:24 UTC by Okki
Modified: 2015-03-01 14:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Debug log level 2 (104.51 KB, text/plain)
2015-02-23 21:24 UTC, Okki
Details
Stack traces (11.22 KB, text/plain)
2015-02-23 21:25 UTC, Okki
Details

Description Okki 2015-02-23 21:24:27 UTC
Created attachment 297716 [details]
Debug log level 2

After creating a new project, choose no preset, and added my video, Pitivi crash.

The video was created in a Fedora 21 VM running on VirtualBox, with GNOME video capture system. The video is watchable without problems with Totem.

The problem persists with the latest daily build Pitivi 64 bits bundle.




General
Complete name                            : Screencast_20-02-2015_19:11:33.webm
Format                                   : WebM
Format version                           : Version 2
File size                                : 908 KiB
Duration                                 : 38s 227ms
Overall bit rate                         : 195 Kbps
Encoded date                             : UTC 2015-02-20 18:11:33
Writing application                      : GStreamer Matroska muxer
Writing library                          : GStreamer plugin version 1.4.4

Video
ID                                       : 1
Format                                   : VP8
Codec ID                                 : V_VP8
Bit rate                                 : 180 Kbps
Width                                    : 1 920 pixels
Height                                   : 961 pixels
Display aspect ratio                     : 1.998
Frame rate mode                          : Variable
Compression mode                         : Lossy
Title                                    : Video
Language                                 : English
Default                                  : Yes
Forced                                   : No
Comment 1 Okki 2015-02-23 21:25:39 UTC
Created attachment 297717 [details]
Stack traces
Comment 2 Thibault Saunier 2015-02-23 23:08:09 UTC
Could you share the file please?
Comment 4 Thibault Saunier 2015-02-24 07:45:19 UTC
Since this bug only reproduces with glimagesink I think it lies around the GL plugins.

It can easily be reproduced with the following steps:

* wget http://demo.ovh.eu/download/332064f256bffa1550c3767f0fc8f4e4/Screencast_20-02-2015_19_11_33.webm
* in gst-plugins-base/tests/example/playback run
   $ ./playback-test 0 /path/to/Screencast_20-02-2015_19_11_33.webm
* Expand "playbin options" and set 'glimagesink' in the "Video Sink" text entry
* Press the Play button

Result:

message from "playbin" (new-clock): GstMessageNewClock, clock=(GstClock)"\(GstSystemClock\)\ GstSystemClock";
0:00:17.703020361 26617 0x7fffc4002770 ERROR              glcontext gstglcontext.c:1068:_gst_gl_debug_callback:<glcontextglx0> high: GL error from API id:1, GL_INVALID_OPERATION in glTexSubImage2D(invalid PBO access)
0:00:17.703107823 26617 0x7fffc4002770 ERROR              glcontext gstglcontext.c:1068:_gst_gl_debug_callback:<glcontextglx0> high: GL error from API id:1, GL_INVALID_OPERATION in glTexSubImage2D(invalid PBO access)

Program received signal SIGSEGV, Segmentation fault.

Thread 140736817264384 (LWP 26625)

  • #0 __memcpy_avx_unaligned
    at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S line 205
  • #1 gst_vp8_dec_handle_frame
    at gstvp8dec.c line 394
  • #2 gst_vp8_dec_handle_frame
    at gstvp8dec.c line 577
  • #3 gst_video_decoder_decode_frame
    at gstvideodecoder.c line 3070
  • #4 gst_video_decoder_chain_forward
    at gstvideodecoder.c line 1953
  • #5 gst_video_decoder_chain
    at gstvideodecoder.c line 2247
  • #6 gst_pad_push_data
    at gstpad.c line 3968
  • #7 gst_pad_push_data
    at gstpad.c line 4201
  • #8 gst_pad_push
    at gstpad.c line 4312
  • #9 gst_multi_queue_loop
    at gstmultiqueue.c line 1233
  • #10 gst_multi_queue_loop
    at gstmultiqueue.c line 1488
  • #11 gst_task_func
    at gsttask.c line 331
  • #12 g_thread_pool_thread_proxy
    at gthreadpool.c line 307
  • #13 g_thread_proxy
    at gthread.c line 764
  • #14 start_thread
    at pthread_create.c line 310
  • #15 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 109
A debugging session is active.

	Inferior 1 [process 26617] will be killed.
Comment 5 Thibault Saunier 2015-03-01 12:00:42 UTC
I just tried again as I had the impression it could be linked to  https://bugzilla.gnome.org/show_bug.cgi?id=744246 and it looks like the trace is now different:

(gdb) bt
  • #0 malloc_consolidate
    at malloc.c line 4151
  • #1 _int_malloc
    at malloc.c line 3420
  • #2 _int_memalign
    at malloc.c line 4399
  • #3 __posix_memalign
    at malloc.c line 3101
  • #4 __posix_memalign
    at malloc.c line 4996
  • #5 slab_allocator_alloc_chunk
    at gslice.c line 1378
  • #6 slab_allocator_alloc_chunk
    at gslice.c line 1252
  • #7 slab_allocator_alloc_chunk
    at gslice.c line 1297
  • #8 g_slice_alloc
    at gslice.c line 731
  • #9 g_slice_alloc
    at gslice.c line 801
  • #10 g_slice_alloc
    at gslice.c line 996
  • #11 g_slice_alloc0
    at gslice.c line 1032
  • #12 _gl_mem_new
    at gstglmemory.c line 762
  • #13 gst_gl_memory_alloc
    at gstglmemory.c line 1274
  • #14 gst_gl_memory_setup_buffer
    at gstglmemory.c line 1421
  • #15 gst_gl_buffer_pool_alloc
    at gstglbufferpool.c line 257
  • #16 do_alloc_buffer
    at gstbufferpool.c line 270
  • #17 default_acquire_buffer
    at gstbufferpool.c line 1103
  • #18 gst_gl_buffer_pool_acquire_buffer
    at gstglbufferpool.c line 300
  • #19 gst_buffer_pool_acquire_buffer
    at gstbufferpool.c line 1211
  • #20 gst_video_decoder_allocate_output_frame
    at gstvideodecoder.c line 3650
  • #21 gst_vp8_dec_handle_frame
    at gstvp8dec.c line 574
  • #22 gst_video_decoder_decode_frame
    at gstvideodecoder.c line 3068
  • #23 gst_video_decoder_chain_forward
    at gstvideodecoder.c line 1952
  • #24 gst_video_decoder_chain
    at gstvideodecoder.c line 2245
  • #25 gst_pad_push_data
    at gstpad.c line 3968
  • #26 gst_pad_push_data
    at gstpad.c line 4201
  • #27 gst_pad_push
    at gstpad.c line 4312
  • #28 gst_multi_queue_loop
    at gstmultiqueue.c line 1233
  • #29 gst_multi_queue_loop
    at gstmultiqueue.c line 1488
  • #30 gst_task_func
    at gsttask.c line 331
  • #31 g_thread_pool_thread_proxy
    at gthreadpool.c line 307
  • #32 g_thread_proxy
    at gthread.c line 764
  • #33 start_thread
    at pthread_create.c line 310
  • #34 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 109

Comment 6 Nicolas Dufresne (ndufresne) 2015-03-01 13:56:23 UTC
I had a quick look, no pinpoint yet. VP8 decoder does not implement direct rendering into GLMemory, so it's not directly bug #744246 (it copies the image to the GstBuffer from downstream pool).

The interesting parts so far is that gst_vp8_dec_image_to_buffer() writes passed the end of GlMemory allocated block. There is a bug in that function, the width used to copy is in pixels instead of bytes. Though for I420 (our case) it makes no difference, and anyway the copy size would be bigger.

It's a video of height 961. That fact it has an odd height is most likely related.
Comment 7 Nicolas Dufresne (ndufresne) 2015-03-01 14:48:08 UTC
commit 283aca3b5151172698efea88891e486e23280d98
Author: Nicolas Dufresne <nicolas.dufresne@collabora.co.uk>
Date:   Sun Mar 1 09:43:32 2015 -0500

    glbufferpool: Fix offset for odd height
    
    We also need to recalculate the offset, since otherwise the frame
    mapping will be forward two lines in the U and V planes (I420) due
    to gst_video_info_align() round up the Y plane to a even number of
    lines.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=745054