Bug#549189: Same problem, but it disappeared after installing debug package..

[Jeroen Nijhof]

Hello,

I had the same problem here -- segmentation fault while
loading  /usr/lib/gstreamer-0.10/libgstlv2.so .
(in Debian/testing, amd64 as well).

I did generate the valgrind report, as suggested. Lot's of '???'
in there, so  I thought I'ld improve the report by installing
libgstreamer0.10-0-dbg. But that made the segmentation fault disappear!!!

And even stranger, after purging libgstreamer0.10-0-dbg, the
segmentation fault does not reappear!!

Unfortunately I overwrote the valgrind output for the crashing case.
In the non-crashing case it reports various leaks as well, but that's
probably just intended / sloppy programming; I've included the start/end
of the valgrind output below (let me know if you want to see the middle bit).
I did have the impression that with the segfault valgrind did take
far longer, and reported far bigger numbers.

Jeroen Nijhof

-----------------------------

==1678== Memcheck, a memory error detector
==1678== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==1678== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info
==1678== Command: gst-inspect-0.10
==1678== 
==1678== 
==1678== HEAP SUMMARY:
==1678==     in use at exit: 1,388,883 bytes in 13,346 blocks
==1678==   total heap usage: 26,959 allocs, 13,613 frees, 2,396,285 bytes allocated

[........]

==1678== 310,135 bytes in 1,623 blocks are possibly lost in loss record 1,516 of 1,516
==1678==    at 0x4C221A7: malloc (vg_replace_malloc.c:195)
==1678==    by 0x5D6B552: g_malloc (in /lib/libglib-2.0.so.0.2200.1)
==1678==    by 0x5D82FC6: g_memdup (in /lib/libglib-2.0.so.0.2200.1)
==1678==    by 0x4EBCB19: gst_registry_binary_read_cache (gstregistrybinary.c:883)
==1678==    by 0x4E507E4: ensure_current_registry (gst.c:938)
==1678==    by 0x4E52457: init_post (gst.c:1128)
==1678==    by 0x5D71A27: g_option_context_parse (in /lib/libglib-2.0.so.0.2200.1)
==1678==    by 0x4063D8: main (gst-inspect.c:1441)
==1678== 
==1678== LEAK SUMMARY:
==1678==    definitely lost: 60 bytes in 1 blocks
==1678==    indirectly lost: 240 bytes in 10 blocks
==1678==      possibly lost: 1,277,957 bytes in 11,778 blocks
==1678==    still reachable: 110,626 bytes in 1,557 blocks
==1678==         suppressed: 0 bytes in 0 blocks
==1678== Reachable blocks (those to which a pointer was found) are not shown.
==1678== To see them, rerun with: --leak-check=full --show-reachable=yes
==1678== 
==1678== For counts of detected and suppressed errors, rerun with: -v
==1678== ERROR SUMMARY: 487 errors from 487 contexts (suppressed: 45 from 26)