GNOME Bugzilla – Bug 599333
Segfault with asfdemuxer
Last modified: 2009-10-27 00:29:09 UTC
While playing the following url mms://195.245.168.21/haydn, I got a nice segfault. See it here: http://paste.pocoo.org/show/146436/ I upgraded my ubuntu packages to the ones found on https://launchpad.net/~gstreamer-developers/+archive/ppa, namely gst-plugins-ugly0.10=0.10.12.3-1~jaunty1 And still got: http://paste.pocoo.org/show/146447/ I've also been asked to say: "19:18:27 < __tim> s0undt3ch, could you please just file a bug, attach your stack trace, mention the URL and say that __tim on IRC observed valgrind errors with the latest git version as well?" Hope all this helps to solve the issue.
I get valgrind warnings too, but only on initialization it seems. I've pasted them below, all look like problems in libmms. ==1921== Syscall param write(buf) points to uninitialised byte(s) ==1921== at 0x5E2E860: __write_nocancel (in /lib/libpthread-2.10.1.so) ==1921== by 0x884C21F: fallback_io_write (mms.c:213) ==1921== by 0x884C83C: send_command (mms.c:470) ==1921== by 0x884DE54: mms_connect (mms.c:1152) ==1921== by 0x8852456: mmsx_connect (mmsx.c:45) ==1921== by 0x8622FC6: gst_mms_start (gstmms.c:436) ==1921== by 0x8A6FD25: gst_base_src_start (gstbasesrc.c:2526) ==1921== by 0x8A75DF7: gst_base_src_activate_push (gstbasesrc.c:2749) ==1921== by 0x4E87A9A: gst_pad_activate_push (gstpad.c:915) ==1921== by 0x4E88646: gst_pad_set_active (gstpad.c:671) ==1921== by 0x4E6A30A: activate_pads (gstelement.c:2632) ==1921== by 0x4E7B8ED: gst_iterator_fold (gstiterator.c:545) ==1921== Address 0x7caf310 is 288 bytes inside a block of size 121,496 alloc'd ==1921== at 0x4C221A7: malloc (vg_replace_malloc.c:195) ==1921== by 0x884DACB: mms_connect (mms.c:1070) ==1921== by 0x8852456: mmsx_connect (mmsx.c:45) ==1921== by 0x8622FC6: gst_mms_start (gstmms.c:436) ==1921== by 0x8A6FD25: gst_base_src_start (gstbasesrc.c:2526) ==1921== by 0x8A75DF7: gst_base_src_activate_push (gstbasesrc.c:2749) ==1921== by 0x4E87A9A: gst_pad_activate_push (gstpad.c:915) ==1921== by 0x4E88646: gst_pad_set_active (gstpad.c:671) ==1921== by 0x4E6A30A: activate_pads (gstelement.c:2632) ==1921== by 0x4E7B8ED: gst_iterator_fold (gstiterator.c:545) ==1921== by 0x4E6A275: iterator_activate_fold_with_resync (gstelement.c:2664) ==1921== by 0x4E6C67E: gst_element_pads_activate (gstelement.c:2701) ==1921== Uninitialised value was created by a heap allocation ==1921== at 0x4C221A7: malloc (vg_replace_malloc.c:195) ==1921== by 0x884DACB: mms_connect (mms.c:1070) ==1921== by 0x8852456: mmsx_connect (mmsx.c:45) ==1921== by 0x8622FC6: gst_mms_start (gstmms.c:436) ==1921== by 0x8A6FD25: gst_base_src_start (gstbasesrc.c:2526) ==1921== by 0x8A75DF7: gst_base_src_activate_push (gstbasesrc.c:2749) ==1921== by 0x4E87A9A: gst_pad_activate_push (gstpad.c:915) ==1921== by 0x4E88646: gst_pad_set_active (gstpad.c:671) ==1921== by 0x4E6A30A: activate_pads (gstelement.c:2632) ==1921== by 0x4E7B8ED: gst_iterator_fold (gstiterator.c:545) ==1921== by 0x4E6A275: iterator_activate_fold_with_resync (gstelement.c:2664) ==1921== by 0x4E6C67E: gst_element_pads_activate (gstelement.c:2701) ==1921==
Oh that code is scary. But that warning here is only a false warning, if the malloc() at mms.c:1070 is followed by a memset() to clear all allocated memory the warning goes away. Problem with that code is, that it does some string operations and doesn't calculate the lengths correctly, instead just adds some bytes to the length to be on the safe side (which is no problem per se because there's always that 0 terminator). But the 1024 byte large string can easily overflow here, but that's not a problem in normal situations ;) Tim, can you still reproduce it with latest GIT?
Created attachment 146234 [details] valgrind log Yes.
This seems to be the same as #581155
*** Bug 581155 has been marked as a duplicate of this bug. ***
Created attachment 146283 [details] GST_DEBUG=*asf*:5 + valgrind log
Fixed the crash: commit 59f6c82c32b377c2ecc78b67cdfedd4e4d7d4096 Author: Thiago Santos <thiago.sousa.santos@collabora.co.uk> Date: Mon Oct 26 17:31:19 2009 -0300 asfdemux: careful to avoid crash on bogus data When receiving bogus data, we have to avoid subtracting a value larger than 'size' from 'size' variable, resulting in a wrap that would make 'size' a really large bogus value. Fixes #599333 But I've been hearing this mms for some time at WMP and it is fine. So I think our mms source is doing something wrong with the stream. I'd rather keep this open for further investigation.
Closing this, a new bug was created to handle the chained asf in this mms stream: #599718