[gstreamer-bugs] [Bug 302017] New: possible segfault

[bugzilla-daemon at bugzilla.gnome.org]

Please DO NOT reply to this by email. All additional comments should be made in
the comments box of this bug report.

 http://bugzilla.gnome.org/show_bug.cgi?id=302017
 GStreamer | gst-ffmpeg | Ver: HEAD CVS

           Summary: possible segfault
           Product: GStreamer
           Version: HEAD CVS
          Platform: Other
        OS/Version: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-ffmpeg
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: rbultje at ronald.bitfreak.net
         QAContact: gstreamer-bugs at lists.sourceforge.net
                CC: all-bugs at bugzilla.gnome.org


gst-ffmpeg muxers send EOS in the _loop() function, using this piece of code:

    av_write_trailer (ffmpegmux->context);
    url_fclose (&ffmpegmux->context->pb);
    ffmpegmux->opened = FALSE;
    gst_element_set_eos (element);

The url_fclose() will send EOS to the peer pads downstream (filesink, usually;
see gstffmpegprotocol.c). The problem here is that this will emit EOS on
filesink, to which applications may respond (some applications have attached EOS
handlers to filesink instead of to the containing pipeline). This may be
followed, in that same context, by a state change, which will re-trigger the
url_fclose() in the _state_change() handler, causing a segfault.

The simple solution is to set the opened flag to FALSE before calling url_fclose():

    av_write_trailer (ffmpegmux->context);
    ffmpegmux->opened = FALSE;
    url_fclose (&ffmpegmux->context->pb);
    gst_element_set_eos (element);

that makes it all work as expected. The same change is needed in _state_change()
as well, although I don't think that can lead to a segfault.

------- You are receiving this mail because: -------
You are the assignee for the bug.
You are the QA contact for the bug.