[FFmpeg-trac] #5971(ffserver:new): ffserver: Segmentation fault when streaming RTSP with ffserver (Always)

FFmpeg trac at avcodec.org
Mon Nov 21 17:17:27 EET 2016


#5971: ffserver: Segmentation fault when streaming RTSP with ffserver (Always)
-------------------------------------+-------------------------------------
             Reporter:  smartzzz     |                     Type:  defect
               Status:  new          |                 Priority:  critical
            Component:  ffserver     |                  Version:  git-
             Keywords:  ffserver     |  master
  SIGSEGV                            |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 When I try to stream a video via ffserver, it always terminate with
 Setmentation fault due to NULL pointer access.

 I run ffserver with following configuration.

 #Server configuration
 --------------------------------
 HTTPPort 8090
 HTTPBindAddress 0.0.0.0
 RTSPPort 8091
 RTSPBindAddress 0.0.0.0
 MaxClients 1000
 MaxBandwidth 10000
 CustomLog -
 <Feed feed1.ffm>
 File /tmp/feed1.ffm
 ACL Allow 127.0.0.1
 </Feed>
 <Stream test1.mp4>
 Feed feed1.ffm
 Format rtp
 VideoFrameRate 30
 VideoBitRate 5000
 VideoSize 640x480
 VideoQMin 3
 VideoQMax 31
 NoAudio
 NoDefaults
 </Stream>

 And run ffmpeg in order to send video feed to server as follows.
 # ffmpeg -f v4l2 -s 640x480 -r 30 -i /dev/video0
 http://localhost:8090/feed1.ffm

 Whenever I played this stream on remote PC, ffserver always terminates
 with Segmentation fault.


 #GDB information
 Program received signal SIGSEGV, Segmentation fault.
 0xb5cf9e38 in memcpy (__len=<optimized out>, __src=<optimized out>,
     __dest=<optimized out>) at /usr/include/bits/string3.h:53
 53        return __builtin___memcpy_chk (__dest, __src, __len, __bos0
 (__dest));
 (gdb) bt
 #0  0xb5cf9e38 in memcpy (__len=<optimized out>, __src=<optimized out>,
     __dest=<optimized out>) at /usr/include/bits/string3.h:53
 #1  av_freep (arg=0xc) at libavutil/mem.c:248
 #2  0xb6182a86 in codec_parameters_reset (par=par at entry=0x0)
     at libavcodec/utils.c:4022
 #3  0xb618876a in avcodec_parameters_from_context (par=0x0,
 codec=0x7f5f7900)
     at libavcodec/utils.c:4082
 #4  0x7f5b9848 in prepare_sdp_description (stream=0x7f5f63c0,
     pbuffer=0xbea2db74, my_ip=...) at ffserver.c:2999
 #5  0x7f5ba9e6 in rtsp_cmd_describe (
     url=0xbea2f8c4 "rtsp://12.23.66.28:8091/test1.mp4", c=0x7f600a00)
     at ffserver.c:3059
 #6  rtsp_parse_request (c=0x7f600a00) at ffserver.c:2935
 #7  0x7f5b2092 in handle_connection (c=0x7f600a00) at ffserver.c:1008
 #8  http_server () at ffserver.c:777
 #9  main (argc=<optimized out>, argv=<optimized out>) at ffserver.c:4032

 From running git bisect, I found that below commit cause this issue.

 commit 9200514ad8717c63f82101dc394f4378854325bf
 Author: Anton Khirnov <anton at khirnov.net>
 Date:   Wed Jun 18 20:42:52 2014 +0200

     lavf: replace AVStream.codec with AVStream.codecpar

     Currently, AVStream contains an embedded AVCodecContext instance,
 which
     is used by demuxers to export stream parameters to the caller and by
     muxers to receive stream parameters from the caller. It is also used
     internally as the codec context that is passed to parsers.

     In addition, it is also widely used by the callers as the decoding
 (when
     demuxer) or encoding (when muxing) context, though this has been
     officially discouraged since Libav 11.

     There are multiple important problems with this approach:
         - the fields in AVCodecContext are in general one of
             * stream parameters
             * codec options
             * codec state
           However, it's not clear which ones are which. It is consequently
           unclear which fields are a demuxer allowed to set or a muxer
 allowed to
           read. This leads to erratic behaviour depending on whether
 decoding or
           encoding is being performed or not (and whether it uses the
 AVStream
           embedded codec context).
         - various synchronization issues arising from the fact that the
 same
           context is used by several different APIs (muxers/demuxers,
           parsers, bitstream filters and encoders/decoders)
 simultaneously, with
           there being no clear rules for who can modify what and the
 different
           processes being typically delayed with respect to each other.
         - avformat_find_stream_info() making it necessary to support
 opening
           and closing a single codec context multiple times, thus
           complicating the semantics of freeing various allocated objects
 in the
           codec context.

     Those problems are resolved by replacing the AVStream embedded codec
     context with a newly added AVCodecParameters instance, which stores
 only
     the stream parameters exported by the demuxers or read by the muxers.

 This issue is same with https://trac.ffmpeg.org/ticket/5869

--
Ticket URL: <https://trac.ffmpeg.org/ticket/5971>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker


More information about the FFmpeg-trac mailing list