GNOME Bugzilla – Bug 403168
[ffmux_flv] crash on buffer after returning FLOW_ERROR previously
Last modified: 2007-02-09 17:37:49 UTC
If executed enough, the following command fails with different errors: gst-launch audiotestsrc ! audio/x-raw-int,rate=44100 ! audioconvert ! audioresample ! audio/x-raw-int,rate=24000 ! lame ! mp3parse ! ffmux_flv ! fakesink The specified rate is not supported by ffmux_flv so gst-lauch shutdown the pipeline, and during the audioresample shutdown the following errors append: - Floating point exception - Segmentation fault - Deadlock
Double free append too.
I can't reproduce this here with latest CVS. Which versions of gstreamer, gst-plugins-base, gst-plugins-ugly and gst-ffmpeg do you have? LC_ALL=C gst-launch audiotestsrc ! audio/x-raw-int,rate=44100 ! audioconvert ! audioresample ! audio/x-raw-int,rate=24000 ! lame ! mp3parse ! ffmux_flv ! fakesink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... 0:00:00.727415000 15849 0x806ebb0 ERROR ffmpeg :0:: flv doesnt support that sample rate, choose from (44100, 22050, 11025) ERROR: from element /pipeline0/ffmux_flv0: Could not configure supporting library. Additional debug info: gstffmpegmux.c(475): gst_ffmpegmux_collected (): /pipeline0/ffmux_flv0: Failed to write file header - check codec settings ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... FREEING pipeline ...
I get a crash about 1 out of 20 times with current CVS of things. Unfortunately I can't reproduce it under valgrind.
Hmm, I got a segfault now with a supported sample rate and ctrl+c and can reproduce this almost always... interesting Let's set this to confirmed then...
I'm using the HEAD version of all. Following are some backtraces I got. Note that these are not from the gst-lauch command I give before but from my application that do little more (have a tee and a queue). All the following error append during the pipeline shutdown. Segmentation Fault Backtraces: ------------------------------ Program received signal SIGSEGV, Segmentation fault.
+ Trace 107094
Thread NaN (LWP 4691)
Thread NaN (LWP 5033)
Thread NaN (LWP 4773)
Thread 2 (Thread -1222952032 (LWP 4897))
This is fixed for me now, with the following commits: 2007-02-09 Tim-Philipp Müller <tim at centricular dot net> * ext/lame/gstlame.c: (gst_lame_sink_event), (gst_lame_chain), (gst_lame_change_state): * ext/lame/gstlame.h: On receiving EOS, we try to push a last buffer with the remaining samples. Don't do that if we got an unclean flow return on the last gst_pad_push(), downstream might not handle this very gracefully (see #403168). * gst/mpegaudioparse/gstmpegaudioparse.c: (gst_mp3parse_chain): Pass flow returns upstream (helps #403168). 2007-02-09 Tim-Philipp Müller <tim at centricular dot net> * ext/ffmpeg/gstffmpegmux.c: (gst_ffmpegmux_request_new_pad), (gst_ffmpegmux_setcaps), (gst_ffmpegmux_collected): Only set the mux->opened flag after we've successfully written the header. This way we don't crash in mysterious ways if we can't write the header for some reason (e.g. due to having accepted caps the format doesn't really allow), then return a GST_FLOW_ERROR, and then still receive another buffer afterwards despite having previously returned FLOW_ERROR (#403168). Also some minor logging improvements. 2007-02-09 Tim-Philipp Müller <tim at centricular dot net> * ext/ffmpeg/gstffmpegmux.c: (gst_ffmpegmux_register): ffmux_flv only accepts mpeg audio with a sample rate of 44100, 22050 or 11025. Fix up the caps in the sink pad template accordingly, so that encoding piplines at least have a chance to automatically negotiate to one of the allowed rates. Primarily an ffmux_flv bug I think, no idea why it crashes in audioresample for you (may thrashed memory). Please re-open if you still get the crash with CVS HEAD of everything (including core).