GNOME Bugzilla – Bug 699518
Segfault inside either GStreamer or gst-plugins-base.
Last modified: 2018-01-25 18:47:44 UTC
In an attempt to replicate an unrelated bug, I wrote this test pipeline: gst-launch-1.0 videotestsrc pattern=black ! "video/x-raw,width=(int)1920,height=(int)1080" ! clockoverlay valignment=top halignment=left font-desc="Sans 8" time-format="%T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T" ! videocrop right=540 bottom=540 ! xvimagesink display=:2 and got an immediate segfault. I then reran the test under the debugger and captured a backtrace of the crash. It can be found here: http://pastebin.com/raw.php?i=ZPRsY7jy Note that I am running the very latest git source (compiled today) for this test.
Can't reproduce this here. Also completely valgrind clean for me. Could you attach the output of the above pipeline when you pass -v to gst-launch-1.0 (so we can see the cap negotiated)? Maybe also the output of running it in valgrind with G_SLICE=always-malloc ?
I'll do the valgrind test shortly. Just adding -v I get: Setting pipeline to PAUSED ... Pipeline is PREROLLING ... /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0.GstPad:src: caps = video/x-raw, format=(string)I420, width=(int)1920, height=(int)1080, framerate=(fraction)30/1 /GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = video/x-raw, format=(string)I420, width=(int)1920, height=(int)1080, framerate=(fraction)30/1 /GstPipeline:pipeline0/GstClockOverlay:clockoverlay0.GstPad:src: caps = video/x-raw, format=(string)I420, width=(int)1920, height=(int)1080, framerate=(fraction)30/1 /GstPipeline:pipeline0/GstVideoCrop:videocrop0.GstPad:src: caps = video/x-raw, format=(string)I420, width=(int)1380, height=(int)540, framerate=(fraction)30/1 /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0.GstPad:sink: caps = video/x-raw, format=(string)I420, width=(int)1380, height=(int)540, framerate=(fraction)30/1 /GstPipeline:pipeline0/GstVideoCrop:videocrop0.GstPad:sink: caps = video/x-raw, format=(string)I420, width=(int)1920, height=(int)1080, framerate=(fraction)30/1 /GstPipeline:pipeline0/GstClockOverlay:clockoverlay0.GstPad:video_sink: caps = video/x-raw, format=(string)I420, width=(int)1920, height=(int)1080, framerate=(fraction)30/1 /GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:sink: caps = video/x-raw, format=(string)I420, width=(int)1920, height=(int)1080, framerate=(fraction)30/1 Caught SIGSEGV
+ Trace 231893
Okay, same thing, but under valgrind (I assumed you wanted memcheck) ==21322== Memcheck, a memory error detector ==21322== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==21322== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==21322== Command: gst-launch-1.0 -v videotestsrc pattern=black ! video/x-raw,width=(int)1920,height=(int)1080 ! clockoverlay valignment=top halignment=left font-desc=Sans\ 8 time-format=%T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T ! videocrop right=540 bottom=540 ! xvimagesink display=:2 ==21322== Setting pipeline to PAUSED ... Pipeline is PREROLLING ... /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0.GstPad:src: caps = video/x-raw, format=(string)I420, width=(int)1920, height=(int)1080, framerate=(fraction)30/1 /GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = video/x-raw, format=(string)I420, width=(int)1920, height=(int)1080, framerate=(fraction)30/1 /GstPipeline:pipeline0/GstClockOverlay:clockoverlay0.GstPad:src: caps = video/x-raw, format=(string)I420, width=(int)1920, height=(int)1080, framerate=(fraction)30/1 /GstPipeline:pipeline0/GstVideoCrop:videocrop0.GstPad:src: caps = video/x-raw, format=(string)I420, width=(int)1380, height=(int)540, framerate=(fraction)30/1 /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0.GstPad:sink: caps = video/x-raw, format=(string)I420, width=(int)1380, height=(int)540, framerate=(fraction)30/1 /GstPipeline:pipeline0/GstVideoCrop:videocrop0.GstPad:sink: caps = video/x-raw, format=(string)I420, width=(int)1920, height=(int)1080, framerate=(fraction)30/1 /GstPipeline:pipeline0/GstClockOverlay:clockoverlay0.GstPad:video_sink: caps = video/x-raw, format=(string)I420, width=(int)1920, height=(int)1080, framerate=(fraction)30/1 /GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:sink: caps = video/x-raw, format=(string)I420, width=(int)1920, height=(int)1080, framerate=(fraction)30/1 Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock ==21322== Thread 3: ==21322== Invalid write of size 2 ==21322== at 0x4C29D74: memcpy (mc_replace_strmem.c:882) ==21322== by 0xA062E08: gst_video_crop_transform_frame (gstvideocrop.c:368) ==21322== by 0x7726BF3: gst_video_filter_transform (gstvideofilter.c:270) ==21322== by 0x7984F49: gst_base_transform_handle_buffer (gstbasetransform.c:2069) ==21322== by 0x7985886: gst_base_transform_chain (gstbasetransform.c:2176) ==21322== by 0x4E91209: gst_pad_chain_data_unchecked (gstpad.c:3673) ==21322== by 0x4E9995A: gst_pad_push_data (gstpad.c:3890) ==21322== by 0x7E35939: gst_base_text_overlay_push_frame (gstbasetextoverlay.c:1703) ==21322== by 0x7E372A7: gst_base_text_overlay_video_chain (gstbasetextoverlay.c:2170) ==21322== by 0x4E91209: gst_pad_chain_data_unchecked (gstpad.c:3673) ==21322== by 0x4E9995A: gst_pad_push_data (gstpad.c:3890) ==21322== by 0x79859B0: gst_base_transform_chain (gstbasetransform.c:2212) ==21322== Address 0xe52029c is 604 bytes inside a block of size 327,680 free'd ==21322== at 0x4C27BE0: realloc (vg_replace_malloc.c:662) ==21322== by 0x84C58A7: ??? (in /usr/lib64/libcairo.so.2.10800.8) ==21322== by 0x84A27C4: ??? (in /usr/lib64/libcairo.so.2.10800.8) ==21322== by 0x84A31B1: ??? (in /usr/lib64/libcairo.so.2.10800.8) ==21322== by 0x84BAB77: ??? (in /usr/lib64/libcairo.so.2.10800.8) ==21322== by 0x84B70D3: ??? (in /usr/lib64/libcairo.so.2.10800.8) ==21322== by 0x84B3D33: ??? (in /usr/lib64/libcairo.so.2.10800.8) ==21322== by 0x84B5979: ??? (in /usr/lib64/libcairo.so.2.10800.8) ==21322== by 0x84C4B9F: ??? (in /usr/lib64/libcairo.so.2.10800.8) ==21322== by 0x84C1310: ??? (in /usr/lib64/libcairo.so.2.10800.8) ==21322== by 0x84AA486: ??? (in /usr/lib64/libcairo.so.2.10800.8) ==21322== by 0x84A494F: cairo_stroke_preserve (in /usr/lib64/libcairo.so.2.10800.8) ==21322== valgrind: m_mallocfree.c:1889 (vgPlain_arena_free): Assertion '(Block*)sb_start == b' failed. ==21322== at 0x38031DA7: report_and_quit (m_libcassert.c:235) ==21322== by 0x38031FE0: vgPlain_assert_fail (m_libcassert.c:309) ==21322== by 0x3803EA65: vgPlain_arena_free (m_mallocfree.c:1889) ==21322== by 0x38003667: create_MC_Chunk (mc_malloc_wrappers.c:165) ==21322== by 0x38003BE0: vgMemCheck_new_block (mc_malloc_wrappers.c:283) ==21322== by 0x3800409A: vgMemCheck_malloc (mc_malloc_wrappers.c:301) ==21322== by 0x3807A58A: vgPlain_scheduler (scheduler.c:1665) ==21322== by 0x380A5A19: run_a_thread_NORETURN (syswrap-linux.c:103) ==21322== by 0x380A5CAA: vgModuleLocal_start_thread_NORETURN (syswrap-linux.c:304) ==21322== by 0x380A8AFD: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==21322== by 0xDEADBEEFDEADBEEE: ??? ==21322== by 0xDEADBEEFDEADBEEE: ??? ==21322== by 0xDEADBEEFDEADBEEE: ??? sched status: running_tid=3 Thread 1: status = VgTs_WaitSys ==21322== at 0x6227253: poll (poll.c:87) ==21322== by 0x5848D7C: ??? (in /usr/lib64/libglib-2.0.so.0.3200.1) ==21322== by 0x5849074: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3200.1) ==21322== by 0x4E69584: gst_bus_poll (gstbus.c:1082) ==21322== by 0x4035A6: event_loop (gst-launch.c:519) ==21322== by 0x404C7F: main (gst-launch.c:1105) Thread 2: status = VgTs_WaitSys ==21322== at 0x5F39D2D: ??? (syscall-template.S:82) ==21322== by 0x586C0B7: g_usleep (in /usr/lib64/libglib-2.0.so.0.3200.1) ==21322== by 0xA26E6FE: gst_xvimagesink_event_thread (xvimagesink.c:582) ==21322== by 0x586A8A4: ??? (in /usr/lib64/libglib-2.0.so.0.3200.1) ==21322== by 0x5F32850: start_thread (pthread_create.c:301) ==21322== by 0xBAFB6FF: ??? Thread 3: status = VgTs_Runnable ==21322== at 0x4C279EE: malloc (vg_replace_malloc.c:270) ==21322== by 0x84A2E10: ??? (in /usr/lib64/libcairo.so.2.10800.8) ==21322== by 0x84BAB77: ??? (in /usr/lib64/libcairo.so.2.10800.8) ==21322== by 0x84B70D3: ??? (in /usr/lib64/libcairo.so.2.10800.8) ==21322== by 0x84B3D33: ??? (in /usr/lib64/libcairo.so.2.10800.8) ==21322== by 0x84B5979: ??? (in /usr/lib64/libcairo.so.2.10800.8) ==21322== by 0x84C4B9F: ??? (in /usr/lib64/libcairo.so.2.10800.8) ==21322== by 0x84C1310: ??? (in /usr/lib64/libcairo.so.2.10800.8) ==21322== by 0x84AA486: ??? (in /usr/lib64/libcairo.so.2.10800.8) ==21322== by 0x84A494F: cairo_stroke_preserve (in /usr/lib64/libcairo.so.2.10800.8) ==21322== by 0x84A4968: cairo_stroke (in /usr/lib64/libcairo.so.2.10800.8) ==21322== by 0x7E35514: gst_base_text_overlay_render_text (gstbasetextoverlay.c:1371) ==21322== by 0x7E3729C: gst_base_text_overlay_video_chain (gstbasetextoverlay.c:2169) ==21322== by 0x4E91209: gst_pad_chain_data_unchecked (gstpad.c:3673) ==21322== by 0x4E9995A: gst_pad_push_data (gstpad.c:3890) ==21322== by 0x79859B0: gst_base_transform_chain (gstbasetransform.c:2212) ==21322== by 0x4E91209: gst_pad_chain_data_unchecked (gstpad.c:3673) ==21322== by 0x4E9995A: gst_pad_push_data (gstpad.c:3890) ==21322== by 0x797E8BF: gst_base_src_loop (gstbasesrc.c:2728) ==21322== by 0x4EC08A6: gst_task_func (gsttask.c:316) ==21322== by 0x586B678: ??? (in /usr/lib64/libglib-2.0.so.0.3200.1) ==21322== by 0x586A8A4: ??? (in /usr/lib64/libglib-2.0.so.0.3200.1) ==21322== by 0x5F32850: start_thread (pthread_create.c:301) ==21322== by 0xC4FC6FF: ??? Thread 4: status = VgTs_WaitSys ==21322== at 0x6227253: poll (poll.c:87) ==21322== by 0x5848D7C: ??? (in /usr/lib64/libglib-2.0.so.0.3200.1) ==21322== by 0x5848E46: g_main_context_iteration (in /usr/lib64/libglib-2.0.so.0.3200.1) ==21322== by 0x5848EA8: ??? (in /usr/lib64/libglib-2.0.so.0.3200.1) ==21322== by 0x586A8A4: ??? (in /usr/lib64/libglib-2.0.so.0.3200.1) ==21322== by 0x5F32850: start_thread (pthread_create.c:301) ==21322== by 0xCEFD6FF: ??? Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks.
Doesn't cause any warnings in valgrind for me. The backtrace looks a bit weird, videocrop should never work on any memory that was touched by cairo (the cairo memory is blended to the video frame by textoverlay), so I expect memory corruption somewhere else already.
(In reply to comment #4) > Doesn't cause any warnings in valgrind for me. The backtrace looks a bit weird, > videocrop should never work on any memory that was touched by cairo (the cairo > memory is blended to the video frame by textoverlay), so I expect memory > corruption somewhere else already. This sounds likely. Is there anything I can do to help track this down?
Maybe you could install debugging symbols for both cairo and pango. It would also be good to know which version of these libraries you are using, and perhaps what distro / distro version.
Our target distro is CentOS 6.4 x86_64 and as that particular distro is quite far behind in its library versions, we were forced to build our own copies of cairo and quite a few other libraries, in order to successfully build gstreamer 1.06. The pango we have installed is a stock pango-1.28.1-7.el6_3.x86_64, and I have now installed the buginfos. The cairo we built ourselves, and it looks like the person involved never produced a buginfo package for it. According to yum, we're running cairo-1.8.8_3.1.el6.x86_64. If you really need debugging info for cairo, it will have to wait until the office is open again on monday, as rebuilding cairo from source will probably require me to install and/or rebuild a bunch of other stuff as well.
Any news on this? We would need a backtrace with all debugging symbols
Sorry for the long delay. Rebuilding cairo for CentOS never worked, even after a week of trying. So, instead I installed everything on an up-to-date debian system and confirmed I could reproduce the bug there. NOW if you need debugging symbols or valgrind output, I can easily oblige. Here is a trace of the crash with full backtrace: sti@timelord:~/Work/src/gstreamer1.0/test$ bash ./bug699518 GNU gdb (GDB) 7.6 (Debian 7.6-5) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/local/bin/gst-launch-1.0...done. (gdb) r Starting program: /usr/local/bin/gst-launch-1.0 videotestsrc pattern=black \! video/x-raw,width=\(int\)1920,height=\(int\)1080 \! clockoverlay valignment=top halignment=left font-desc=Sans\ 8 time-format=%T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T \! videocrop right=540 bottom=540 \! xvimagesink display=:1 warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Setting pipeline to PAUSED ... [New Thread 0x7fffed679700 (LWP 5194)] [New Thread 0x7fffece78700 (LWP 5195)] Pipeline is PREROLLING ... [New Thread 0x7fffe7fff700 (LWP 5196)] Program received signal SIGSEGV, Segmentation fault.
+ Trace 232555
Thread 140737167984384 (LWP 5195)
I tried it with valgrind as well, but it refused to run: sti@timelord:~/Work/src/gstreamer1.0/test$ ./bug699518.sh -M Running with Valgrind --memcheck valgrind '--suppressions=/home/sti/Work/src/gstreamer1.0/test/./gst.supp' '--suppressions=/home/sti/Work/src/gstreamer1.0/test/./gst-libav.supp' '--suppressions=/home/sti/Work/src/gstreamer1.0/test/./gst-plugins-base.supp' '--suppressions=/home/sti/Work/src/gstreamer1.0/test/./gst-plugins-good.supp' '--suppressions=/home/sti/Work/src/gstreamer1.0/test/./gst-plugins-bad.supp' '--suppressions=/home/sti/Work/src/gstreamer1.0/test/./gst-plugins-ugly.supp' '--read-var-info=yes' '--tool=memcheck' '--track-origins=yes' '--leak-check=full' '--show-reachable=no' '--show-possibly-lost=no' gst-launch-1.0 videotestsrc 'pattern=black' ! 'video/x-raw,width=(int)1920,height=(int)1080' ! clockoverlay 'valignment=top' 'halignment=left' 'font-desc='\''Sans' '8'\' 'time-format='\''%T' %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T '%T'\' videocrop 'right=540' 'bottom=540' ! xvimagesink 'display=:1' ==5809== Memcheck, a memory error detector ==5809== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==5809== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==5809== Command: gst-launch-1.0 videotestsrc pattern=black ! video/x-raw,width=(int)1920,height=(int)1080 ! clockoverlay valignment=top halignment=left font-desc='Sans 8' time-format='%T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T' videocrop right=540 bottom=540 ! xvimagesink display=:1 ==5809== GStreamer has detected that it is running inside valgrind. It might now take different code paths to ease debugging. Of course, this may also lead to different bugs. Setting pipeline to PAUSED ... Pipeline is PREROLLING ... ERROR: from element /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0: Internal data flow error. Additional debug info: gstbasesrc.c(2865): gst_base_src_loop (): /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0: streaming task paused, reason not-linked (-1) ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... ==5809== ==5809== HEAP SUMMARY: ==5809== in use at exit: 1,118,938 bytes in 5,451 blocks ==5809== total heap usage: 58,103 allocs, 52,652 frees, 17,958,686 bytes allocated ==5809== ==5809== 8 bytes in 1 blocks are definitely lost in loss record 121 of 2,624 ==5809== at 0x4C2935B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5809== by 0x5D2CDC1: strdup (strdup.c:42) ==5809== by 0x7656324: orc_program_add_destination_full (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x7651146: orc_bytecode_parse_function (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x7655F6B: orc_program_new_from_static_bytecode (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x6FA0ADB: video_test_src_orc_splat_u32 (tmp-orc.c:194) ==5809== by 0x6F9EA4B: gst_video_test_src_unicolor (videotestsrc.c:549) ==5809== by 0x6F9CAB3: gst_video_test_src_fill (gstvideotestsrc.c:877) ==5809== by 0x7412452: gst_base_src_default_create (gstbasesrc.c:1439) ==5809== by 0x7414EF0: gst_base_src_get_range (gstbasesrc.c:2392) ==5809== by 0x74169CA: gst_base_src_loop (gstbasesrc.c:2665) ==5809== by 0x4EC2308: gst_task_func (gsttask.c:316) ==5809== ==5809== 8 bytes in 1 blocks are definitely lost in loss record 122 of 2,624 ==5809== at 0x4C2935B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5809== by 0x5D2CDC1: strdup (strdup.c:42) ==5809== by 0x7656287: orc_program_add_source_full (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x765110E: orc_bytecode_parse_function (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x7655F6B: orc_program_new_from_static_bytecode (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x71D2C2B: video_orc_pack_I420 (tmp-orc.c:1112) ==5809== by 0x71B69FD: pack_planar_420 (video-format.c:115) ==5809== by 0x6F9E5A9: convert_hline_generic (videotestsrc.c:1202) ==5809== by 0x6F9E189: videotestsrc_convert_tmpline (videotestsrc.c:275) ==5809== by 0x6F9EA5B: gst_video_test_src_unicolor (videotestsrc.c:550) ==5809== by 0x6F9CAB3: gst_video_test_src_fill (gstvideotestsrc.c:877) ==5809== by 0x7412452: gst_base_src_default_create (gstbasesrc.c:1439) ==5809== ==5809== 8 bytes in 1 blocks are definitely lost in loss record 123 of 2,624 ==5809== at 0x4C2935B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5809== by 0x5D2CDC1: strdup (strdup.c:42) ==5809== by 0x7656324: orc_program_add_destination_full (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x7651146: orc_bytecode_parse_function (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x7655F6B: orc_program_new_from_static_bytecode (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x71D2B4B: video_orc_unpack_I420 (tmp-orc.c:873) ==5809== by 0x71B6AC0: unpack_planar_420 (video-format.c:93) ==5809== by 0x71CF217: gst_video_blend (video-blend.c:336) ==5809== by 0x71CFFAE: gst_video_overlay_composition_blend (video-overlay-composition.c:491) ==5809== by 0x78CEEE6: gst_base_text_overlay_push_frame (gstbasetextoverlay.c:1697) ==5809== by 0x78D1A34: gst_base_text_overlay_video_chain (gstbasetextoverlay.c:2170) ==5809== by 0x4E945A4: gst_pad_push_data (gstpad.c:3711) ==5809== ==5809== 8 bytes in 1 blocks are definitely lost in loss record 124 of 2,624 ==5809== at 0x4C2935B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5809== by 0x5D2CDC1: strdup (strdup.c:42) ==5809== by 0x7656324: orc_program_add_destination_full (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x7651146: orc_bytecode_parse_function (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x7655F6B: orc_program_new_from_static_bytecode (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x71D374B: video_orc_unpack_BGRA (tmp-orc.c:3841) ==5809== by 0x71CF243: gst_video_blend (video-blend.c:338) ==5809== by 0x71CFFAE: gst_video_overlay_composition_blend (video-overlay-composition.c:491) ==5809== by 0x78CEEE6: gst_base_text_overlay_push_frame (gstbasetextoverlay.c:1697) ==5809== by 0x78D1A34: gst_base_text_overlay_video_chain (gstbasetextoverlay.c:2170) ==5809== by 0x4E945A4: gst_pad_push_data (gstpad.c:3711) ==5809== by 0x741EB8A: gst_base_transform_chain (gstbasetransform.c:2237) ==5809== ==5809== 8 bytes in 1 blocks are definitely lost in loss record 125 of 2,624 ==5809== at 0x4C2935B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5809== by 0x5D2CDC1: strdup (strdup.c:42) ==5809== by 0x7656287: orc_program_add_source_full (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x765110E: orc_bytecode_parse_function (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x7655F6B: orc_program_new_from_static_bytecode (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x71D374B: video_orc_unpack_BGRA (tmp-orc.c:3841) ==5809== by 0x71CF243: gst_video_blend (video-blend.c:338) ==5809== by 0x71CFFAE: gst_video_overlay_composition_blend (video-overlay-composition.c:491) ==5809== by 0x78CEEE6: gst_base_text_overlay_push_frame (gstbasetextoverlay.c:1697) ==5809== by 0x78D1A34: gst_base_text_overlay_video_chain (gstbasetextoverlay.c:2170) ==5809== by 0x4E945A4: gst_pad_push_data (gstpad.c:3711) ==5809== by 0x741EB8A: gst_base_transform_chain (gstbasetransform.c:2237) ==5809== ==5809== 24 bytes in 3 blocks are definitely lost in loss record 1,111 of 2,624 ==5809== at 0x4C2935B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5809== by 0x5D2CDC1: strdup (strdup.c:42) ==5809== by 0x7656324: orc_program_add_destination_full (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x7651146: orc_bytecode_parse_function (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x7655F6B: orc_program_new_from_static_bytecode (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x71D2C2B: video_orc_pack_I420 (tmp-orc.c:1112) ==5809== by 0x71B69FD: pack_planar_420 (video-format.c:115) ==5809== by 0x6F9E5A9: convert_hline_generic (videotestsrc.c:1202) ==5809== by 0x6F9E189: videotestsrc_convert_tmpline (videotestsrc.c:275) ==5809== by 0x6F9EA5B: gst_video_test_src_unicolor (videotestsrc.c:550) ==5809== by 0x6F9CAB3: gst_video_test_src_fill (gstvideotestsrc.c:877) ==5809== by 0x7412452: gst_base_src_default_create (gstbasesrc.c:1439) ==5809== ==5809== 24 bytes in 3 blocks are definitely lost in loss record 1,112 of 2,624 ==5809== at 0x4C2935B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5809== by 0x5D2CDC1: strdup (strdup.c:42) ==5809== by 0x7656287: orc_program_add_source_full (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x765110E: orc_bytecode_parse_function (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x7655F6B: orc_program_new_from_static_bytecode (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x71D2B4B: video_orc_unpack_I420 (tmp-orc.c:873) ==5809== by 0x71B6AC0: unpack_planar_420 (video-format.c:93) ==5809== by 0x71CF217: gst_video_blend (video-blend.c:336) ==5809== by 0x71CFFAE: gst_video_overlay_composition_blend (video-overlay-composition.c:491) ==5809== by 0x78CEEE6: gst_base_text_overlay_push_frame (gstbasetextoverlay.c:1697) ==5809== by 0x78D1A34: gst_base_text_overlay_video_chain (gstbasetextoverlay.c:2170) ==5809== by 0x4E945A4: gst_pad_push_data (gstpad.c:3711) ==5809== ==5809== 40 bytes in 1 blocks are definitely lost in loss record 1,522 of 2,624 ==5809== at 0x4C2935B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5809== by 0x7655F1B: orc_program_new (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x7655F5D: orc_program_new_from_static_bytecode (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x6FA0ADB: video_test_src_orc_splat_u32 (tmp-orc.c:194) ==5809== by 0x6F9EA4B: gst_video_test_src_unicolor (videotestsrc.c:549) ==5809== by 0x6F9CAB3: gst_video_test_src_fill (gstvideotestsrc.c:877) ==5809== by 0x7412452: gst_base_src_default_create (gstbasesrc.c:1439) ==5809== by 0x7414EF0: gst_base_src_get_range (gstbasesrc.c:2392) ==5809== by 0x74169CA: gst_base_src_loop (gstbasesrc.c:2665) ==5809== by 0x4EC2308: gst_task_func (gsttask.c:316) ==5809== by 0x55F6B95: g_thread_pool_thread_proxy (gthreadpool.c:309) ==5809== by 0x55F61D4: g_thread_proxy (gthread.c:798) ==5809== ==5809== 40 bytes in 1 blocks are definitely lost in loss record 1,523 of 2,624 ==5809== at 0x4C2935B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5809== by 0x7655F1B: orc_program_new (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x7655F5D: orc_program_new_from_static_bytecode (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x71D2C2B: video_orc_pack_I420 (tmp-orc.c:1112) ==5809== by 0x71B69FD: pack_planar_420 (video-format.c:115) ==5809== by 0x6F9E5A9: convert_hline_generic (videotestsrc.c:1202) ==5809== by 0x6F9E189: videotestsrc_convert_tmpline (videotestsrc.c:275) ==5809== by 0x6F9EA5B: gst_video_test_src_unicolor (videotestsrc.c:550) ==5809== by 0x6F9CAB3: gst_video_test_src_fill (gstvideotestsrc.c:877) ==5809== by 0x7412452: gst_base_src_default_create (gstbasesrc.c:1439) ==5809== by 0x7414EF0: gst_base_src_get_range (gstbasesrc.c:2392) ==5809== by 0x74169CA: gst_base_src_loop (gstbasesrc.c:2665) ==5809== ==5809== 40 bytes in 1 blocks are definitely lost in loss record 1,524 of 2,624 ==5809== at 0x4C2935B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5809== by 0x7655F1B: orc_program_new (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x7655F5D: orc_program_new_from_static_bytecode (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x71D2B4B: video_orc_unpack_I420 (tmp-orc.c:873) ==5809== by 0x71B6AC0: unpack_planar_420 (video-format.c:93) ==5809== by 0x71CF217: gst_video_blend (video-blend.c:336) ==5809== by 0x71CFFAE: gst_video_overlay_composition_blend (video-overlay-composition.c:491) ==5809== by 0x78CEEE6: gst_base_text_overlay_push_frame (gstbasetextoverlay.c:1697) ==5809== by 0x78D1A34: gst_base_text_overlay_video_chain (gstbasetextoverlay.c:2170) ==5809== by 0x4E945A4: gst_pad_push_data (gstpad.c:3711) ==5809== by 0x741EB8A: gst_base_transform_chain (gstbasetransform.c:2237) ==5809== by 0x4E945A4: gst_pad_push_data (gstpad.c:3711) ==5809== ==5809== 40 bytes in 1 blocks are definitely lost in loss record 1,525 of 2,624 ==5809== at 0x4C2935B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5809== by 0x7655F1B: orc_program_new (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x7655F5D: orc_program_new_from_static_bytecode (in /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.18.0) ==5809== by 0x71D374B: video_orc_unpack_BGRA (tmp-orc.c:3841) ==5809== by 0x71CF243: gst_video_blend (video-blend.c:338) ==5809== by 0x71CFFAE: gst_video_overlay_composition_blend (video-overlay-composition.c:491) ==5809== by 0x78CEEE6: gst_base_text_overlay_push_frame (gstbasetextoverlay.c:1697) ==5809== by 0x78D1A34: gst_base_text_overlay_video_chain (gstbasetextoverlay.c:2170) ==5809== by 0x4E945A4: gst_pad_push_data (gstpad.c:3711) ==5809== by 0x741EB8A: gst_base_transform_chain (gstbasetransform.c:2237) ==5809== by 0x4E945A4: gst_pad_push_data (gstpad.c:3711) ==5809== by 0x7416C3C: gst_base_src_loop (gstbasesrc.c:2779) ==5809== ==5809== 2,218 (768 direct, 1,450 indirect) bytes in 1 blocks are definitely lost in loss record 2,563 of 2,624 ==5809== at 0x4C2B72E: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5809== by 0x8721E59: FcPatternObjectInsertElt (fcpat.c:435) ==5809== by 0x87224E1: FcPatternObjectListAdd (fcpat.c:567) ==5809== by 0x871F88A: FcFontRenderPrepare (fcmatch.c:573) ==5809== by 0x871FD6F: FcFontMatch (fcmatch.c:713) ==5809== by 0x825DF24: pango_fc_fontset_get_font_at (pangofc-fontmap.c:761) ==5809== by 0x825E0CC: pango_fc_fontset_foreach (pangofc-fontmap.c:999) ==5809== by 0x7D00B57: get_shaper_and_font (pango-context.c:1258) ==5809== by 0x7D00F7B: itemize_state_process_run (pango-context.c:1460) ==5809== by 0x7D01D79: pango_itemize_with_base_dir (pango-context.c:1565) ==5809== by 0x7D0909B: pango_layout_check_lines (pango-layout.c:3945) ==5809== by 0x7D0A187: pango_layout_get_extents_internal (pango-layout.c:2534) ==5809== ==5809== 6,024 bytes in 1 blocks are definitely lost in loss record 2,602 of 2,624 ==5809== at 0x4C2B514: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5809== by 0xA29429E: ??? (in /usr/lib/x86_64-linux-gnu/nvidia/current/libGL.so.325.15) ==5809== ==5809== LEAK SUMMARY: ==5809== definitely lost: 7,040 bytes in 17 blocks ==5809== indirectly lost: 4,250 bytes in 199 blocks ==5809== possibly lost: 0 bytes in 0 blocks ==5809== still reachable: 495,688 bytes in 1,336 blocks ==5809== suppressed: 611,960 bytes in 3,899 blocks ==5809== Reachable blocks (those to which a pointer was found) are not shown. ==5809== To see them, rerun with: --leak-check=full --show-reachable=yes ==5809== ==5809== For counts of detected and suppressed errors, rerun with: -v ==5809== ERROR SUMMARY: 13 errors from 13 contexts (suppressed: 171 from 171) sti@timelord:~/Work/src/gstreamer1.0/test$
Try adding a -- in front of gst-launch-1.0 in the valgrind command, maybe it gets confused by one of the commandline arguments Also please check if the stride used by videocrop in that code is the same that xvimagesink expects
Not sure how to check the stride. However it looks like I was misquoting things for Valgrind. Here's what I get now: $ valgrind --suppressions=gstreamer/common/gst.supp --suppressions=gst-libav/tests/check/gst-libav.supp --suppressions=gst-plugins-base/tests/check/gst-plugins-base.supp --suppressions=gst-plugins-good/tests/check/gst-plugins-good.supp --suppressions=gst-plugins-bad/tests/check/gst-plugins-bad.supp --suppressions=gst-plugins-ugly/tests/check/gst-plugins-ugly.supp --read-var-info=yes --tool=memcheck --track-origins=yes --leak-check=full --show-reachable=no --show-possibly-lost=no -- gst-launch-1.0 videotestsrc pattern=black ! video/x-raw,width=1920,height=1080 ! clockoverlay valignment=top halignment=left font-desc="Sans 8" time-format="%T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T" ! videocrop right=540 bottom=540 ! xvimagesink display=:1.3 ==20597== Memcheck, a memory error detector ==20597== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==20597== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==20597== Command: gst-launch-1.0 videotestsrc pattern=black ! video/x-raw,width=1920,height=1080 ! clockoverlay valignment=top halignment=left font-desc=Sans\ 8 time-format=%T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T ! videocrop right=540 bottom=540 ! xvimagesink display=:1.3 ==20597== GStreamer has detected that it is running inside valgrind. It might now take different code paths to ease debugging. Of course, this may also lead to different bugs. Setting pipeline to PAUSED ... Pipeline is PREROLLING ... --20597-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2 --20597-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2 ==20597== Thread 3 videotestsrc0:sr: ==20597== Invalid write of size 2 ==20597== at 0x4C2CB96: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:882) ==20597== by 0xD160BD6: gst_video_crop_transform_frame (gstvideocrop.c:370) ==20597== by 0x71F2BE6: gst_video_filter_transform (gstvideofilter.c:270) ==20597== by 0x745A9E6: gst_base_transform_handle_buffer (gstbasetransform.c:2117) ==20597== by 0x745B221: gst_base_transform_chain (gstbasetransform.c:2224) ==20597== by 0x4E9910D: gst_pad_push_data (gstpad.c:3836) ==20597== by 0x7B149D7: gst_base_text_overlay_push_frame (gstbasetextoverlay.c:1896) ==20597== by 0x7B16E8F: gst_base_text_overlay_video_chain (gstbasetextoverlay.c:2366) ==20597== by 0x4E9910D: gst_pad_push_data (gstpad.c:3836) ==20597== by 0x745B3E4: gst_base_transform_chain (gstbasetransform.c:2260) ==20597== by 0x4E9910D: gst_pad_push_data (gstpad.c:3836) ==20597== by 0x7453044: gst_base_src_loop (gstbasesrc.c:2835) ==20597== Address 0x105b929c is not stack'd, malloc'd or (recently) free'd ==20597== Caught SIGSEGV
+ Trace 233854
Thread 140737199073024 (LWP 20660)
This is what I get from a gdb session: $ gdb --args gst-launch-1.0 videotestsrc pattern=black ! video/x-raw,width=1920,height=1080 ! clockoverlay valignment=top halignment=left font-desc="Sans 8" time-format="%T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T" ! videocrop right=540 bottom=540 ! xvimagesink display=:1.3GNU gdb (GDB) 7.6.2 (Debian 7.6.2-1.1+b1) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/local/bin/gst-launch-1.0...done. (gdb) r Starting program: /usr/local/bin/gst-launch-1.0 videotestsrc pattern=black \! video/x-raw,width=1920,height=1080 \! clockoverlay valignment=top halignment=left font-desc=Sans\ 8 time-format=%T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T \! videocrop right=540 bottom=540 \! xvimagesink display=:1.3 warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Setting pipeline to PAUSED ... [New Thread 0x7fffef41f700 (LWP 20659)] [New Thread 0x7fffeec1e700 (LWP 20660)] Pipeline is PREROLLING ... [New Thread 0x7fffee41d700 (LWP 20661)] Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock (gst-launch-1.0:20654): GStreamer-CRITICAL **: gst_mini_object_lock: assertion 'GST_MINI_OBJECT_IS_LOCKABLE (object)' failed Program received signal SIGSEGV, Segmentation fault.
+ Trace 233855
Note, running valgrind with G_SLICE=always_malloc would be better. I would worry about this: (gst-launch-1.0:20654): GStreamer-CRITICAL **: gst_mini_object_lock: assertion 'GST_MINI_OBJECT_IS_LOCKABLE (object)' failed To break on that, G_DEBUG=fatal_criticals
$ gdb --args gst-launch-1.0 --gst-fatal-warnings videotestsrc pattern=black ! video/x-raw,width=1920,height=1080 ! clockoverlay valignment=top halignment=left font-desc="Sans 8" time-format="%T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T" ! videocrop right=540 bottom=540 ! xvimagesink display=:1.3 GNU gdb (GDB) 7.6.2 (Debian 7.6.2-1.1+b1) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/local/bin/gst-launch-1.0...done. (gdb) r Starting program: /usr/local/bin/gst-launch-1.0 --gst-fatal-warnings videotestsrc pattern=black \! video/x-raw,width=1920,height=1080 \! clockoverlay valignment=top halignment=left font-desc=Sans\ 8 time-format=%T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T\ %T \! videocrop right=540 bottom=540 \! xvimagesink display=:1.3 warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000 warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Setting pipeline to PAUSED ... [New Thread 0x7fffef41f700 (LWP 20841)] [New Thread 0x7fffeec1e700 (LWP 20842)] Pipeline is PREROLLING ... [New Thread 0x7fffee41d700 (LWP 20843)] Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock (gst-launch-1.0:20837): GStreamer-CRITICAL **: gst_mini_object_lock: assertion 'GST_MINI_OBJECT_IS_LOCKABLE (object)' failed Program received signal SIGTRAP, Trace/breakpoint trap.
+ Trace 233856
Thread 140737199073024 (LWP 20842)
Sorry this is taking so much time. I have retested it here with GStreamer 1.6 and master (Cairo 1.14.2), and still could not reproduce any of the reported issues. This all seems like an external bug that happen to write in GStreamer objects. At the same time, a lot of work has been done on the cairo based text overlays (and was langed in 1.6). Maybe it's worth doing a test there. At best we could bump from dependency version, or catch broken dependencies in our build system ?
I am now running under Centos 7.1, and I just tried again, and I can still reproduce this error, even using gstreamer 1.6 and cairo 1.12.14-6.el7 Its not a serious bug, as I only ever encounter it in this test, but I do find it mysterious. Is there any tests I can do that might help track it down?
Not sure what to do with this. If we can't reproduce it we can't fix it, and you haven't been able to narrow down the cause either as far as I can tell. Do you know if this still happens with recent versions of GStreamer? Do you actually need this time-format="%T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T %T" to trigger the bug, or does it also happen without it or with a single %T ?
I can no longer reproduce the bug either, so I can only assume that some fix has already taken care of the problem.
Great, thanks for confirming.