ASan builds (my 34.x and your latest 35.0a1 tinderbox build) report a nasty looking segfault when the attached video is played. I don't have all the debugging symbols at hand, but this seems to happen within gstreamer, so this is likely Linux specific. I'm running up-to-date Debian (Wheezy). To reproduce: $ firefox-asan segv.m4v 2>&1 | grep ERROR ==23769==ERROR: AddressSanitizer: SEGV on unknown address 0x62c000100000 (pc 0x7f43f9a0e1fe sp 0x7f43f8e14820 bp 0x62900069c180 T50)

crash report: https://crash-stats.mozilla.com/report/index/eff60288-835e-40d0-bd52-4d35d2141013

It looks like this is crashing in some kind of gstreamer library. Chris, do you know who could investigate this? Thanks.

jwwang may have time for this?

sure.

If I launch the browser and ctrl-o to open the file (segv.m4v), chances are it doesn't crash and I can get the following logs: 2014-10-15 07:05:43.875851 UTC - 1860437760[6120003dbc40]: Decoder=613000301940 Decoding Media Headers 2014-10-15 07:05:43.875960 UTC - 1860437760[6120003dbc40]: GStreamerReader(61a00026f480) starting metadata pipeline 2014-10-15 07:05:43.907266 UTC - 1860437760[6120003dbc40]: GStreamerReader(61a00026f480) configuring random access, len 2353933 2014-10-15 07:05:44.189481 UTC - 1860437760[6120003dbc40]: GStreamerReader(61a00026f480) read metadata pipeline failed to preroll: error 2014-10-15 07:05:44.189555 UTC - 1860437760[6120003dbc40]: GStreamerReader(61a00026f480) read metadata error: This file is corrupt and cannot be played.: qtdemux.(5479): qtdemux_stbl_init (): /GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/GstQTDemux:qtdemux0 2014-10-15 07:05:44.190517 UTC - 1860437760[6120003dbc40]: GStreamerReader(61a00026f480) starting metadata pipeline 2014-10-15 07:05:44.191126 UTC - 1860437760[6120003dbc40]: GStreamerReader(61a00026f480) configuring random access, len 2353933 2014-10-15 07:05:44.195035 UTC - 1860437760[6120003dbc40]: GStreamerReader(61a00026f480) read metadata pipeline failed to preroll: error 2014-10-15 07:05:44.195086 UTC - 1860437760[6120003dbc40]: GStreamerReader(61a00026f480) read metadata error: This file is corrupt and cannot be played.: qtdemux.c(5479): qtdemux_stbl_init (): /GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin1/GstDecodeBin2:decodebin21/GstQTDemux:qtdemux1 2014-10-15 07:05:44.195679 UTC - 1860437760[6120003dbc40]: GStreamerReader(61a00026f480) starting metadata pipeline 2014-10-15 07:05:44.196018 UTC - 1860437760[6120003dbc40]: GStreamerReader(61a00026f480) configuring random access, len 2353933 2014-10-15 07:05:44.199179 UTC - 1860437760[6120003dbc40]: GStreamerReader(61a00026f480) read metadata pipeline failed to preroll: error 2014-10-15 07:05:44.199231 UTC - 1860437760[6120003dbc40]: GStreamerReader(61a00026f480) read metadata error: This file is corrupt and cannot be played.: qtdemux.c(5479): qtdemux_stbl_init (): /GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin2/GstDecodeBin2:decodebin22/GstQTDemux:qtdemux2 [30799] WARNING: Decoder=613000301940 ReadMetadata failed, res=80004005 HasValidMedia=0: file /media/jwwang/DATA/codebase/mozilla-central2/content/media/MediaDecoderStateMachine.cpp, line 1958 The file is corrupted and causes crash in gstreamer threads. There isn't much we can do with it. I also try other players: VLC player => no crash, no play at all, gnome player (https://wiki.gnome.org/Apps/Videos) => crash. What can we do next about this bug?

I'm not sure what we can do about a crash in system GStreamer. Alessandro, do you know if this crash in GStreamer on files such as https://bugzilla.mozilla.org/attachment.cgi?id=8501665 is fixed in a new GStreamer version?

I tried gstreamer1.0 which also crashed on the file.

(In reply to Chris Pearce (:cpearce) from comment #6) > I'm not sure what we can do about a crash in system GStreamer. > > Alessandro, do you know if this crash in GStreamer on files such as > https://bugzilla.mozilla.org/attachment.cgi?id=8501665 is fixed in a new > GStreamer version? It doesn't crash with master. I'll see if I can pin point when it was fixed exactly.

Stack trace with symbols from jw_wang: #0 0x00007ffff7031e4e in ?? () from /lib/x86_64-linux-gnu/libc.so.6 11:17 #1 0x00007ffff7b0c8ab in gst_buffer_fill () from /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0 11:17 #2 0x00007ffff5d5dbd6 in gst_qtdemux_handle_esds (qtdemux=0x93e170, stream=0x7ffff0001a00, list=0x7ffff00028f0, esds=<optimized out>) at qtdemux.c:10197 11:17 #3 0x00007ffff5d75c65 in qtdemux_parse_trak (trak=0x7ffff0001200, qtdemux=0x93e170) at qtdemux.c:8158 11:17 #4 qtdemux_parse_tree (qtdemux=qtdemux@entry=0x93e170) at qtdemux.c:9935 11:17 #5 0x00007ffff5d7b7b6 in gst_qtdemux_chain (sinkpad=<optimized out>, parent=0x93e170, inbuf=<optimized out>) at qtdemux.c:4725

With more debug symbols installed: #0 __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:36 #1 0x00007ffff7b0c8ab in memcpy (__len=2097154, __src=0x7ffff0004201, __dest=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/string3.h:51 #2 gst_buffer_fill (buffer=buffer@entry=0x7fffe8014620, offset=<optimized out>, offset@entry=0, src=src@entry=0x7ffff0004201, size=size@entry=2097154) at gstbuffer.c:1595 #3 0x00007ffff5d5dbd6 in gst_qtdemux_handle_esds (qtdemux=0x7d2050, stream=0x7ffff000cc00, list=0x7ffff0002cf0, esds=<optimized out>) at qtdemux.c:10197 #4 0x00007ffff5d75c65 in qtdemux_parse_trak (trak=0x7ffff0001200, qtdemux=0x7d2050) at qtdemux.c:8158 #5 qtdemux_parse_tree (qtdemux=qtdemux@entry=0x7d2050) at qtdemux.c:9935 #6 0x00007ffff5d7b7b6 in gst_qtdemux_chain (sinkpad=<optimized out>, parent=0x7d2050, inbuf=<optimized out>) at qtdemux.c:4725 #7 0x00007ffff7b36d08 in gst_pad_chain_data_unchecked (data=0x7fffe80067c0, type=4112, pad=0x7b8770) at gstpad.c:3760 #8 gst_pad_push_data (pad=0x7b8540, type=type@entry=4112, data=<optimized out>, data@entry=0x7fffe80067c0) at gstpad.c:3990 #9 0x00007ffff7b3d9b6 in gst_pad_push (pad=<optimized out>, buffer=buffer@entry=0x7fffe80067c0) at gstpad.c:4093 #10 0x00007ffff6222eb0 in gst_queue_push_one (queue=0x7ba0d0) at gstqueue.c:1115 #11 gst_queue_loop (pad=<optimized out>) at gstqueue.c:1244 #12 0x00007ffff7b64549 in gst_task_func (task=0x7da050) at gsttask.c:316 #13 0x00007ffff75eb89c in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #14 0x00007ffff75eaf15 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #15 0x00007ffff7367182 in start_thread (arg=0x7ffff4ba1700) at pthread_create.c:312 #16 0x00007ffff7093fbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Arun looked at this and identified the patches from git that fix the crash. They're here: http://people.freedesktop.org/~arun/patches/gst-plugins-good-1.2-esds-crash. We can probably get at least fedora debian ubuntu and gentoo to apply them if you're interested. Can someone invite Arun to this bug please (or make the bug public)? He's arun@accosted.net.

Done.

Thanks for adding me. How should we proceed here? The fix is already available in the latest stable release of GStreamer, but current stable Fedora/Ubuntu/Debian/etc. might not be able to update their packages. We could try to push out another 1.2 release on the GStreamer side and push this out (it's a bit of work/time to get done upstream since this is maintenance on an older version), or take the patches to distros for inclusion.

We deprecated support for gstreamer.

GStreamer support has been removed.