GNOME Bugzilla – Bug 772845
SIGSEGV when running GST_TRACER examples
Last modified: 2016-10-17 09:18:29 UTC
I'm running some of the examples from: https://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/design/part-tracing.txt Because I want to start using the tracer But I'm frequently (does not happen all the time) getting a segmentation fault for this one: GST_DEBUG="GST_TRACER:7" GST_TRACERS="stats;rusage" GST_DEBUG_FILE=trace.log gst-launch-1.0 fakesrc num-buffers=10 sizetype=fixed ! queue ! fakesink gst-stats-1.0 trace.log - print some pipeline stats on exit root@qt5022-fglrx:~# GST_DEBUG="GST_TRACER:7" GST_TRACERS="stats;rusage" GST_DEBUG_FILE=trace.log gst-launch-1.0 fakesrc num-buffers=10 sizetype=fixed ! queue ! fakesink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 0:00:00.004619717 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... Caught SIGSEGV
+ Trace 236736
The seg fault does not seem to happen if I remove either of these: GST_TRACERS="stats;rusage" GST_DEBUG_FILE=trace.log The other examples seem to work fine
Can you get another backtrace with debug symbols for GLib and GStreamer installed? Thanks!
root@qt5022-fglrx:~# GST_DEBUG="GST_TRACER:7" GST_TRACERS="stats;rusage" GST_DEBUG_FILE=trace.log gst-launch-1.0 fakesrc num-buffers=10 sizetype=fixed ! queue ! fakesink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 0:00:00.001075586 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... Caught SIGSEGV
+ Trace 236738
That looks problematic, might be memory corruption before that crash already. Can you also run in valgrind (with G_SLICE=always-malloc and --track-origins=yes on valgrind)?
root@qt5022-fglrx:~# G_SLICE=always-malloc GST_DEBUG="GST_TRACER:7" GST_TRACERS="stats;rusage" GST_DEBUG_FILE=trace.log valgrind --track-origins=yes gst-launch-1.0 fakesrc num-buffers=10 sizetype=fixed ! queue ! fakesink ==1702== Memcheck, a memory error detector ==1702== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==1702== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==1702== Command: gst-launch-1.0 fakesrc num-buffers=10 sizetype=fixed ! queue ! fakesink ==1702== Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 0:00:00.021224892 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... ==1702== Invalid free() / delete / delete[] / realloc() ==1702== at 0x4C2B06A: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==1702== by 0x6DCF1FC: free_trace_values (gstrusage.c:88) ==1702== by 0x6DCF1FC: free_thread_stats (gstrusage.c:146) ==1702== by 0x53E1CC9: g_hash_table_remove_all_nodes.part.0 (ghash.c:548) ==1702== by 0x53E2B71: g_hash_table_remove_all_nodes (ghash.c:1425) ==1702== by 0x53E2B71: g_hash_table_remove_all (ghash.c:1428) ==1702== by 0x53E2BA5: g_hash_table_destroy (ghash.c:1122) ==1702== by 0x6DCFD64: gst_rusage_tracer_finalize (gstrusage.c:263) ==1702== by 0x516E321: g_object_unref (gobject.c:3179) ==1702== by 0x4ED52D3: _priv_gst_tracing_deinit (gsttracerutils.c:150) ==1702== by 0x4E61294: gst_deinit (gst.c:967) ==1702== by 0x4035D2: main (gst-launch.c:1191) ==1702== Address 0x6c09da8 is 8 bytes inside a block of size 32 alloc'd ==1702== at 0x4C29F50: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==1702== by 0x53F7B80: g_malloc (gmem.c:94) ==1702== by 0x540DBB2: g_slice_alloc (gslice.c:1007) ==1702== by 0x540E225: g_slice_alloc0 (gslice.c:1032) ==1702== by 0x6DCF796: make_trace_values (gstrusage.c:79) ==1702== by 0x6DCF796: do_stats (gstrusage.c:203) ==1702== by 0x4E8B632: gst_element_post_message (gstelement.c:1765) ==1702== by 0x4E9EFFD: do_stream_status.isra.2 (gstpad.c:5915) ==1702== by 0x4ED1800: gst_task_func (gsttask.c:303) ==1702== by 0x5417DA8: g_thread_pool_thread_proxy (gthreadpool.c:307) ==1702== by 0x5417444: g_thread_proxy (gthread.c:778) ==1702== by 0x56BB345: start_thread (pthread_create.c:333) ==1702== ==1702== Invalid free() / delete / delete[] / realloc() ==1702== at 0x4C2B06A: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==1702== by 0x6DCFD7B: free_trace_values (gstrusage.c:88) ==1702== by 0x6DCFD7B: gst_rusage_tracer_finalize (gstrusage.c:264) ==1702== by 0x516E321: g_object_unref (gobject.c:3179) ==1702== by 0x4ED52D3: _priv_gst_tracing_deinit (gsttracerutils.c:150) ==1702== by 0x4E61294: gst_deinit (gst.c:967) ==1702== by 0x4035D2: main (gst-launch.c:1191) ==1702== Address 0x6aedb18 is 8 bytes inside a block of size 32 alloc'd ==1702== at 0x4C29F50: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==1702== by 0x53F7B80: g_malloc (gmem.c:94) ==1702== by 0x540DBB2: g_slice_alloc (gslice.c:1007) ==1702== by 0x540E225: g_slice_alloc0 (gslice.c:1032) ==1702== by 0x6DCF379: make_trace_values (gstrusage.c:79) ==1702== by 0x6DCF379: gst_rusage_tracer_init (gstrusage.c:358) ==1702== by 0x518B757: g_type_create_instance (gtype.c:1874) ==1702== by 0x516E863: g_object_new_internal (gobject.c:1779) ==1702== by 0x5170569: g_object_new_valist (gobject.c:2038) ==1702== by 0x51708BB: g_object_new (gobject.c:1622) ==1702== by 0x4ED50FB: _priv_gst_tracing_init (gsttracerutils.c:120) ==1702== by 0x4E6094D: init_post (gst.c:730) ==1702== by 0x53FCE77: g_option_context_parse (goption.c:2159) ==1702== ==1702== ==1702== HEAP SUMMARY: ==1702== in use at exit: 216,658 bytes in 2,377 blocks ==1702== total heap usage: 25,248 allocs, 22,875 frees, 3,231,518 bytes allocated ==1702== ==1702== LEAK SUMMARY: ==1702== definitely lost: 464 bytes in 5 blocks ==1702== indirectly lost: 133 bytes in 5 blocks ==1702== possibly lost: 5,036 bytes in 64 blocks ==1702== still reachable: 198,329 bytes in 2,205 blocks ==1702== of which reachable via heuristic: ==1702== length64 : 240 bytes in 6 blocks ==1702== newarray : 1,568 bytes in 18 blocks ==1702== suppressed: 0 bytes in 0 blocks ==1702== Rerun with --leak-check=full to see details of leaked memory ==1702== ==1702== For counts of detected and suppressed errors, rerun with: -v ==1702== ERROR SUMMARY: 4 errors from 2 contexts (suppressed: 0 from 0)
Thanks, that looks useful :)
But I don't understand it from a short look, this needs some further investigation. I also can't reproduce it here on my machine. What GLib version on which platform with which glibc is this?
Well, it is an embedded platform, running a linux kernel 4.7. root@qt5022-fglrx:~# /lib/libc.so.6 GNU C Library (GNU libc) stable release version 2.23, by Roland McGrath et al. Copyright (C) 2016 Free Software Foundation, Inc. Compiled by GNU CC version 5.3.0. If you can't reproduce it it might be some incompatibility of headers or something in our system. I will take a look and report back.
Yes that seems likely. The problem here is that the allocation in gstrusage.c:79 is freed again in gstrusage.c:88, but according to valgrind what happens is that "allocation_address + 8" is freed instead.
So it turns out it is the same bug as this: https://bugzilla.gnome.org/show_bug.cgi?id=764985 And we are running 1.8.0 which is before it was fixed
Thanks for tracking this down :) *** This bug has been marked as a duplicate of bug 764985 ***