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 681359 - shmsink segfaults under certain conditions
shmsink segfaults under certain conditions
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: 1.1.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-08-07 09:24 UTC by Guillaume Emont (guijemont)
Modified: 2013-02-28 23:02 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Guillaume Emont (guijemont) 2012-08-07 09:24:23 UTC 
Here's a way to reproduce, run:
gst-launch-1.0 videotestsrc ! "video/x-raw, format=(string)I420, width=(int)1920, height=(int)1080, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive,  framerate=(fraction)1000/1" ! shmsink socket-path=/tmp/video-socket

And while it's running, launch:
gst-launch-1.0 -v shmsrc socket-path=/tmp/video-socket  ! fakesink silent=false

This results in a segmentation fault. Here is what seems to be the relevant stack trace:

+ Trace 230631

Thread 2 (Thread 0x7f696d22b700 (LWP 21614))

  • #0 nanosleep
    at ../sysdeps/unix/syscall-template.S line 82
  • #1 g_usleep
    at /build/buildd/glib2.0-2.32.3/./glib/gtimer.c line 259
  • #2 fault_spin
    at gst-launch.c line 149
  • #3 fault_handler_sigaction
    at gst-launch.c line 129
  • #4 <signal handler called>
  • #5 __memcpy_ssse3_back
    at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S line 1631
  • #6 gst_buffer_extract
    at gstbuffer.c line 1501
  • #7 gst_shm_sink_render
    at gstshmsink.c line 450
  • #8 gst_base_sink_chain_unlocked
    at gstbasesink.c line 3184
  • #9 gst_base_sink_chain_main
    at gstbasesink.c line 3295
  • #10 gst_base_sink_chain
    at gstbasesink.c line 3324
  • #11 gst_pad_chain_data_unchecked
    at gstpad.c line 3587
  • #12 gst_pad_push_data
    at gstpad.c line 3800
  • #13 gst_pad_push
    at gstpad.c line 3903
  • #14 gst_base_transform_chain
    at gstbasetransform.c line 2190
  • #15 gst_pad_chain_data_unchecked
    at gstpad.c line 3587
  • #16 gst_pad_push_data
    at gstpad.c line 3800
  • #17 gst_pad_push
    at gstpad.c line 3903
  • #18 gst_base_src_loop
    at gstbasesrc.c line 2689
  • #19 gst_task_func
    at gsttask.c line 316
  • #20 default_func
    at gsttaskpool.c line 70
  • #21 g_thread_pool_thread_proxy
    at /build/buildd/glib2.0-2.32.3/./glib/gthreadpool.c line 309
  • #22 g_thread_proxy
    at /build/buildd/glib2.0-2.32.3/./glib/gthread.c line 801
  • #23 start_thread
    at pthread_create.c line 308
  • #24 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 112
  • #25 ?? 






Comment 1


Guillaume Emont (guijemont)





          2012-08-07 12:42:09 UTC
        



This is due to the default shm-size being too small in that case. Things seem to work by increasing it.
A check should be added somewhere (in sp_writer_alloc_bloc()?) to check we don't ask for blocks that are too big.






Comment 2


Levente Farkas





          2012-08-27 09:31:43 UTC
        



imho it's a must! none of the program should segfault under any cases!






Comment 3


Olivier Crête





          2013-02-28 02:07:22 UTC
        



There were two bugs here, one in the allocator, which wasn't correctly checking the end of the area in this case. So the first patch fixes the bug.

But then it would hang forever, so the second patch checks if it will be ever possible to complete an allocation request.

commit 684811cddf60f43df14b2fd7a64207f5566b9a32
Author: Olivier Crête <olivier.crete@collabora.com>
Date:   Wed Feb 27 21:05:38 2013 -0500

    shmsink: Error out if memory area is smaller than buffer

commit 7a77b41d6a86e98ed60716ece907602ec530ac9c
Author: Olivier Crête <olivier.crete@collabora.com>
Date:   Wed Feb 27 20:57:56 2013 -0500

    shm: Make sure to not allocate blocks larger than the shared mem area
    
    Fixes https://bugzilla.gnome.org/show_bug.cgi?id=681359






Comment 4


Levente Farkas





          2013-02-28 11:57:39 UTC
        



would be nice to add to 0.10 too






Comment 5


Olivier Crête





          2013-02-28 18:20:38 UTC
        



just because I like you

in 0.10 it is






Comment 6


Levente Farkas





          2013-02-28 23:02:57 UTC
        



whooow:-)