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 302017 - possible segfault
possible segfault
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-libav
git master
Other All
: Normal normal
: 0.8.5
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-04-26 09:21 UTC by Ronald Bultje
Modified: 2005-05-01 10:15 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ronald Bultje 2005-04-26 09:21:41 UTC
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.
Comment 1 Ronald Bultje 2005-05-01 10:15:38 UTC
done.