GNOME Bugzilla – Bug 748571
faad: crash in gst_faad_set_format
Last modified: 2015-05-24 22:26:01 UTC
Firefox (37.0.2) crashes when html5 media with AAC audio is encountered. Playing OPUS or mp3 streams works fine. gstreamer-1.4.5, faad2-2.7 Program received signal SIGSEGV, Segmentation fault.
+ Trace 235010
Thread 140736399255296 (LWP 417450)
youtube, etc. work with the ffmpeg plugin, so there's an easy workaround.
With today's Fedora 22, I can reliably reproduce this segv when playing an mp4 file (e.g. mp3s work fine). Also, this only started today; looking at what changed when I upgraded today: Upgraded a52dec-0.7.4-19.fc21.x86_64 (unknown) Upgrade 0.7.4-19.fc22.x86_64 @rpmfusion-free @rpmfusion-free Upgraded faad2-1:2.7-6.fc21.x86_64 (unknown) Upgrade 1:2.7-6.fc22.x86_64 @rpmfusion-free Upgraded faad2-libs-1:2.7-6.fc21.x86_64 (unknown) Upgrade 1:2.7-6.fc22.x86_64 @rpmfusion-free Upgraded gstreamer1-libav-1.4.3-1.fc21.x86_64 (unknown) Upgrade 1.4.3-1.fc22.x86_64 @rpmfusion-free Upgraded gstreamer1-plugins-bad-freeworld-1.4.3-1.fc21.x86_64 (unknown) Upgrade 1.4.3-1.fc22.x86_64 @rpmfusion-free So it could be one of those.. % gdb --args gst-launch-1.0 playbin uri=file:///home/djcb/test.mp4 GNU gdb (GDB) Fedora 7.9-11.fc22 Copyright (C) 2015 Free Software Foundation, Inc. [...] Reading symbols from gst-launch-1.0...Reading symbols from /usr/lib/debug/usr/bin/gst-launch-1.0.debug...done. done. gdb% r Starting program: /usr/bin/gst-launch-1.0 playbin uri=file:///home/djcb/test.mp4 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Setting pipeline to PAUSED ... Pipeline is PREROLLING ... [New Thread 0x7fffee8f1700 (LWP 32072)] [New Thread 0x7fffe7fff700 (LWP 32074)] [New Thread 0x7fffe77fe700 (LWP 32075)] [New Thread 0x7fffda803700 (LWP 32076)] [New Thread 0x7fffee0f0700 (LWP 32073)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffe77fe700 (LWP 32075)] gst_memory_unmap (mem=0x7fff00000000, info=info@entry=0x7fffe77fd9c0) at gstmemory.c:339 339 mem->allocator->mem_unmap (mem); gdb% thread apply all bt
+ Trace 235043
Thread 4 (Thread 0x7fffe77fe700 (LWP 32075))
Thread 3 (Thread 0x7fffe7fff700 (LWP 32074))
Thread 2 (Thread 0x7fffee8f1700 (LWP 32072))
Interestingly, I can play the track when using valgrind; and valgrind doesn't show any errors, just a few leaks (which may be false alarms anyway) % G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --leak-check=full --show-possibly-lost=no gst-launch-1.0 playbin uri=file:///home/djcb/test.mp4 ==20562== Memcheck, a memory error detector ==20562== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==20562== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==20562== Command: gst-launch-1.0 playbin uri=file:///home/djcb/test.mp4 ==20562== Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstPulseSinkClock ^Chandling interrupt. Interrupt: Stopping pipeline ... Execution ended after 0:00:15.418107339 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... ==20562== ==20562== HEAP SUMMARY: ==20562== in use at exit: 748,785 bytes in 4,816 blocks ==20562== total heap usage: 106,910 allocs, 102,094 frees, 19,312,118 bytes allocated ==20562== ==20562== 153 bytes in 1 blocks are definitely lost in loss record 3,600 of 3,795 ==20562== at 0x4C28C0F: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==20562== by 0x55E8CA9: g_malloc (gmem.c:97) ==20562== by 0x55FFF62: g_slice_alloc (gslice.c:1007) ==20562== by 0x4E60949: _sysmem_new_block (gstallocator.c:414) ==20562== by 0x4E6AB51: gst_buffer_new_allocate (gstbuffer.c:673) ==20562== by 0x10B72319: gst_qtdemux_handle_esds.isra.29 (qtdemux.c:10525) ==20562== by 0x10B85835: qtdemux_parse_trak (qtdemux.c:8425) ==20562== by 0x10B85835: qtdemux_parse_tree (qtdemux.c:10233) ==20562== by 0x10B8BE28: gst_qtdemux_loop_state_header (qtdemux.c:3149) ==20562== by 0x10B8BE28: gst_qtdemux_loop (qtdemux.c:4360) ==20562== by 0x4EC8B00: gst_task_func (gsttask.c:316) ==20562== by 0x560ACCD: g_thread_pool_thread_proxy (gthreadpool.c:307) ==20562== by 0x560A334: g_thread_proxy (gthread.c:764) ==20562== by 0x5ADE554: start_thread (pthread_create.c:333) ==20562== ==20562== 384 bytes in 6 blocks are definitely lost in loss record 3,683 of 3,795 ==20562== at 0x4C28C0F: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==20562== by 0x4014681: dl_open_worker (dl-open.c:468) ==20562== by 0x400F513: _dl_catch_error (dl-error.c:187) ==20562== by 0x40135D2: _dl_open (dl-open.c:652) ==20562== by 0x58D3FC8: dlopen_doit (dlopen.c:66) ==20562== by 0x400F513: _dl_catch_error (dl-error.c:187) ==20562== by 0x58D4630: _dlerror_run (dlerror.c:163) ==20562== by 0x58D4060: dlopen@@GLIBC_2.2.5 (dlopen.c:87) ==20562== by 0x5396910: _g_module_open (gmodule-dl.c:97) ==20562== by 0x5396910: g_module_open (gmodule.c:573) ==20562== by 0x4EA83EB: gst_plugin_load_file (gstplugin.c:736) ==20562== by 0x4EA91DB: gst_plugin_load_by_name (gstplugin.c:1256) ==20562== by 0x4EA9AFC: gst_plugin_feature_load (gstpluginfeature.c:111) ==20562== ==20562== 16,384 bytes in 1 blocks are definitely lost in loss record 3,789 of 3,795 ==20562== at 0x4C28C0F: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==20562== by 0x55E8CA9: g_malloc (gmem.c:97) ==20562== by 0x55F3066: quark_new (gquark.c:276) ==20562== by 0x55F3066: quark_from_string (gquark.c:177) ==20562== by 0x55F3066: g_quark_from_static_string (gquark.c:237) ==20562== by 0x514FFA8: gobject_init_ctor (gtype.c:4395) ==20562== by 0x400F669: call_init.part.0 (dl-init.c:72) ==20562== by 0x400F77A: call_init (dl-init.c:30) ==20562== by 0x400F77A: _dl_init (dl-init.c:120) ==20562== by 0x4000CC9: ??? (in /usr/lib64/ld-2.21.so) ==20562== by 0x2: ??? ==20562== by 0xFFEFFFBEA: ??? ==20562== by 0xFFEFFFBF9: ??? ==20562== by 0xFFEFFFC01: ??? ==20562== ==20562== LEAK SUMMARY: ==20562== definitely lost: 16,921 bytes in 8 blocks ==20562== indirectly lost: 0 bytes in 0 blocks ==20562== possibly lost: 15,026 bytes in 228 blocks ==20562== still reachable: 688,926 bytes in 4,385 blocks ==20562== suppressed: 0 bytes in 0 blocks ==20562== Reachable blocks (those to which a pointer was found) are not shown. ==20562== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==20562== ==20562== For counts of detected and suppressed errors, rerun with: -v ==20562== ERROR SUMMARY: 222 errors from 222 contexts (suppressed: 0 from 0) G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --leak-check=full playbi 12.54s user 0.42s system 53% cpu 24.076 total
Question: does the file/stream played back have multiple audio (AAC) tracks by any chance?
I don't think so.... how can I tell? In any case, its reproducible e.g. with the very first example at http://download.wavetlan.com/SVV/Media/HTTP/http-mp4.htm gst-launch-1.0 playbin uri='http://download.wavetlan.com/SVV/Media/HTTP/H264/Talkinghead_Media/H264_test1_Talkinghead_mp4_480x360.mp4'
It has just one audio stream (and I was thinking of another bug which was not faad after all though, I misremembered).
There's also a thread on the fedora mailing list about this for what it's worth: https://lists.fedoraproject.org/pipermail/desktop/2015-May/012015.html Seems to imply it's an interaction between gst-vaapi and gst-libav, might just be coincidence of course (or could trigger a bug in decodebin/playbin because multiple decoders are tried or such).
Analysis here: https://bugzilla.redhat.com/show_bug.cgi?id=1219320
commit 1f738ca5b8711ca5532a326cd646312e60484863 Author: Wim Taymans <wtaymans@redhat.com> Date: Wed May 13 16:23:26 2015 +0200 fix faad2 version check On fedora 22, the output of cpp inserts extra debug comments, which makes our regexp for the faad2 version check fail. This in turn causes it to compile with the wrong arguments passed which then causes stack corruption and crashes. Fix this by only checking for the version (which should be by itself on a single line). This is potentially less safe, it might be possible that a similar string would appear in a later version in the header file. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=748571
*** Bug 749461 has been marked as a duplicate of this bug. ***
*** Bug 749807 has been marked as a duplicate of this bug. ***