GNOME Bugzilla – Bug 737199
rtph264depay seg fault with IQEye camera
Last modified: 2015-02-05 01:01:27 UTC
Created attachment 286897 [details] Logging for rtph264depay Summary: Streaming H264 from an IQEye IP camera results in a Segmentation Fault for gstreamer 1.4.1. Details: The following pipeline fails with an IQEye camera and gstreamer 1.4.1 : gst-launch-1.0 rtspsrc location="rtsp://admin:admin@192.168.103.124/rtsp/stream1" ! rtph264depay ! fakesink However, this pipeline does work with gst-launch-0.10 (Provided in Ubuntu 14.04) Looking at the stack trace, it appears the issue is associated with a gst_buffer_new_and_alloc() call in gstrtph264depay.c. See stack trace below : Program received signal SIGSEGV, Segmentation fault.
+ Trace 234120
Thread 140736146175744 (LWP 32599)
Also, before the process crashes several gstreamer critical messages are posted : ** (gst-launch-1.0:385): CRITICAL **: gst_adapter_take_buffer: assertion 'nbytes > 0' failed (gst-launch-1.0:385): GStreamer-CRITICAL **: gst_buffer_map_range: assertion 'GST_IS_BUFFER (buffer)' failed 0:00:00.391883630 385 0x7fffd4002540 DEBUG rtph264depay gstrtph264depay.c:678:gst_rtp_h264_depay_handle_nal:<rtph264depay0> handle NAL type 8 (gst-launch-1.0:385): GStreamer-CRITICAL **: gst_buffer_get_sizes_range: assertion 'GST_IS_BUFFER (buffer)' failed (gst-launch-1.0:385): GStreamer-CRITICAL **: gst_buffer_copy_region: assertion 'buffer != NULL' failed (gst-launch-1.0:385): GStreamer-CRITICAL **: gst_buffer_map_range: assertion 'GST_IS_BUFFER (buffer)' failed (gst-launch-1.0:385): GStreamer-CRITICAL **: gst_buffer_unmap: assertion 'GST_IS_BUFFER (buffer)' failed (gst-launch-1.0:385): GStreamer-CRITICAL **: gst_buffer_unmap: assertion 'GST_IS_BUFFER (buffer)' failed (gst-launch-1.0:385): GStreamer-CRITICAL **: gst_mini_object_unref: assertion 'mini_object != NULL' failed I have attached a log file that contains the output of the process with gst-debug=rtph264depay:5.
Can you run this pipeline under gdb with G_DEBUG=fatal_warnings so we stop at the first of those assertions? It likely is the root cause. Also, perhaps you can provide a GDP payloaded stream from your camera so we can reproduce the issue? gst-launch-1.0 -e rtspsrc location="rtsp://admin:admin@192.168.103.124/rtsp/stream1" ! gdppay ! filesink location=stream.gdp Let it run for some time that you judge would be enough to reproduce the issue and then ctrl-c and wait for it to close the file. Did you try with git master to see if it is still reproducible?
Further tests show that the pipeline fails for versions 1.4.1, 1.4.3, and 1.4.5. However the pipeline functions properly for versions 0.10 and 1.2.4. Here is the output for the pipeline with gstreamer 1.4.5 in gdb with G_DEBUG=fatal_warnings: [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Setting pipeline to PAUSED ... [New Thread 0x7ffff36f1700 (LWP 28795)] Pipeline is live and does not need PREROLL ... [New Thread 0x7ffff2ef0700 (LWP 28796)] Progress: (open) Opening Stream Progress: (connect) Connecting to rtsp://admin:admin@192.168.103.91/rtsp/stream1 [New Thread 0x7ffff199f700 (LWP 28797)] Progress: (open) Retrieving server options [New Thread 0x7ffff119e700 (LWP 28798)] Progress: (open) Retrieving media info Progress: (request) SETUP stream 0 [New Thread 0x7fffe3fff700 (LWP 28799)] Progress: (request) SETUP stream 1 Progress: (open) Opened Stream Setting pipeline to PLAYING ... New clock: GstSystemClock Progress: (request) Sending PLAY request [New Thread 0x7fffe37fe700 (LWP 28800)] [New Thread 0x7fffe2ffd700 (LWP 28801)] [New Thread 0x7fffe27fc700 (LWP 28802)] [New Thread 0x7fffe1ffb700 (LWP 28803)] [New Thread 0x7fffe17fa700 (LWP 28804)] [New Thread 0x7fffe0ff9700 (LWP 28805)] [New Thread 0x7fffc3fff700 (LWP 28806)] [New Thread 0x7fffc37fe700 (LWP 28807)] Progress: (request) Sending PLAY request Progress: (request) Sent PLAY request [New Thread 0x7fffc2ffd700 (LWP 28808)] [New Thread 0x7fffc27fc700 (LWP 28809)] [New Thread 0x7fffc1ffb700 (LWP 28810)] [New Thread 0x7fffc17fa700 (LWP 28811)] ** (gst-launch-1.0:28791): CRITICAL **: gst_adapter_take_buffer: assertion 'nbytes > 0' failed Program received signal SIGTRAP, Trace/breakpoint trap.
+ Trace 234618
Thread 140736439756544 (LWP 28811)
The GDP Payload file was too large to post, so I've shared it with google drive at the following link: https://drive.google.com/file/d/0B1--lpqjOQNwX1RzWlJHWWxLNThNeVNVanRLZW82R0FBMmpZ/view?usp=sharing This is the GDP payload for the IQEye camera generated with the following pipeline: gst-launch-1.0 -e rtspsrc location="rtsp://admin:admin@192.168.103.124/rtsp/stream1" ! gdppay ! filesink location=stream.gdp
Created attachment 296064 [details] [review] rtph264depay: prevent trying to get 0 bytes from adapter Thanks for the quick reply. Could you check if this patch fixes the issue for you?
The patch fixes this issue. Thanks for the help.
commit a6d73797d091a0e4ac33eaf516056103f7ffb1e8 Author: Thiago Santos <thiagoss@osg.samsung.com> Date: Wed Feb 4 02:25:44 2015 -0300 rtph264depay: prevent trying to get 0 bytes from adapter This causes an assertion and would lead to getting a NULL instead of a buffer. Without proper checking this would easily lead to a segfault https://bugzilla.gnome.org/show_bug.cgi?id=737199 And in 1.4: commit fe99398062dc95cfff2d47c46fcc7be94d46abcc Author: Thiago Santos <thiagoss@osg.samsung.com> Date: Wed Feb 4 02:25:44 2015 -0300 rtph264depay: prevent trying to get 0 bytes from adapter This causes an assertion and would lead to getting a NULL instead of a buffer. Without proper checking this would easily lead to a segfault https://bugzilla.gnome.org/show_bug.cgi?id=737199