GNOME Bugzilla – Bug 151064
asfdemux crash
Last modified: 2004-12-22 21:47:04 UTC
I have a wma file that crashes gstreamer when using: filesrc ! typefind ! asfdemux ! audio/x-raw-int ! fakesink but not when using filesrc ! asfdemux ! audio/x-raw-int ! fakesink Here are a bunch of explanations from Company about typefind which may be relevant: <Company> the buffers are sized differently <Company> because typefind caches data while typefinding and then seeks back to the first position after the cached data <Company> and there's a discont after the seek I investigated a bit more using --gst-debug=asfdemux:5, and found out that at the beginning both pipelines seem to process the same data (the traces are the same), but after a few calls to asf_demux_handle_data, the traces start to differ. After adding a bit of debugging stuff to asfdemux, I managed to figure out that right before the traces start to differ, the gst_bytestream_flush call at the end of gst_asf_demux_process_chunk returns FALSE in the pipeline using typefind (the crashing one), and TRUE in the pipeline without it. I don't know asfdemux enough to know how to handle that case though...
I can provide the wma file if necessary.
Isn't this a duplicate of bug #149742 ? FWIW, I think it crashes in g_atomic_read_int() due to GST_BUFFER_REFCOUNT_VALUE() getting used on a NULL buffer in a GST_DEBUG(). Inserting a g_assert(buffer) in front of every GST_DEBUG where the ref count macro is used leads to: ** ERROR **: file gstasfdemux.c: line 1223 (gst_asf_demux_process_chunk): assertion failed: (buffer) Cheers -Tim
Please provide the file. Also, first retest if current CVS reproduces it if you wish.
IIRC the file in question was http://kh3.org/~fv/1.wma Doesn't seem to crash any longer (can't play it either though, just goes into EOS after extracting the tags). Cheers -Tim
I independently stumbled over this bug and found a fix for it (for version 0.8.4 of gst-plugins): the short-short version: gst_bytestream_peek() does not initialize the returned buffer pointer; gst_asf_demux_process_chunk() calls gst_bytestream_peek() without checking its return value, thus accessing the uninitialized buffer pointer, which causes the SIGSEGV. I also looked at CVS HEAD, the code is still vulnerable to this uninitialized pointer bug; so if anything changed, then the only possibility would be that gst_asf_demux_process_chunk() will not get any 0-byte chunks any more (but I did not verify this). Detail are on https://bugzilla.ubuntulinux.org/show_bug.cgi?id=1919. I will attach a patch here. Please change NEEDINFO to NEW/ASSIGNED, I'm not allowed to do that.
Created attachment 32162 [details] [review] patch to fix this segfault if gst_bytestream_peek() returns 0, the function just exits, thus avoiding access to the uninitialized buffer. A more robust solution would probably be to have gst_bytestream_peek() return an initialized 0-byte buffer instead (you should do that in addition).
Actually, if bytestream_peek() returns 0, there's either a read error or a pending event (eos, discont, interrupt, ...). ASFdemux should handle events like other elements (mpeg, avi, matroska, ogg, quicktime) do. For now, the above patch will probably make it work fine, though.
Maybe bytestream_peek() returns 0 also on other occasions (as Ronald says), but it definitively returns 0 if you ask for 0 bytes to be peeked. That is the source of this specific bug. Can someone please reopen this?
OK, that makes sense. 0-byte chunks are painful... Anyway, I applied your patch. Thanks.