Where did you get the caps from?

Can you reproduce this? If yes, how? (small sample program?)

Have you run your code through valgrind?

the caps are in an on_pad_added callback

caps = gst_pad_get_caps(pad);
gchar * caps_as_string = gst_caps_to_string(caps);

you can find here a test media that show the issue here:

http://77.43.75.110/temp/2012_07_27_19_45_24_455_recovered.mov

please run with:

gst-launch filesrc location=/tmp/2012_07_27_19_45_24_455_recovered.mov ! qtdemux name=demux demux. ! queue  ! jpegdec ! xvimagesink demux. ! queue ! adpcmdec ! alsasink

the media was produced with gstreamer itself, in this particular case the recording was interrupted by a system shutdown and the media was recovered with qtmoovrecover with a pipeline like this:

qtmoovrecover recovery-input=.. broken-input=.. fixed-output=..

the gst-launch pipeline provided errors out for me because adpcmdec can't decode a block or three.

Could you run your application or gst-launch-0.10 (with -0.10 suffix!) in valgrind please to see what that shows?

Hi, 

please note that you have to use gst-launch -v to trigger the segfault, sorry for omitting this in my original report,

valgrind show the following output (if can attach the whole output if you want):

==6849== Thread 6:
==6849== Invalid read of size 1
==6849==    at 0x4EC5F18: gst_value_serialize_buffer (stdio2.h:34)
==6849==    by 0x4EC94C6: gst_value_serialize (gstvalue.c:4054)
==6849==    by 0x4EAE8DE: priv_gst_structure_append_to_gstring (gststructure.c:1809)
==6849==    by 0x4E6A5EE: gst_caps_to_string (gstcaps.c:2078)
==6849==    by 0x4E6A7BF: gst_caps_transform_to_string (gstcaps.c:2158)
==6849==    by 0x5153F47: g_value_transform (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.3)
==6849==    by 0x515779B: g_strdup_value_contents (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.3)
==6849==    by 0x4E5B6DA: gst_object_default_deep_notify (gstobject.c:607)
==6849==    by 0x512ECA1: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.3)
==6849==    by 0x513FD70: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.3)
==6849==    by 0x5148098: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.3)
==6849==    by 0x5148241: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.3)
==6849==    by 0x4E5AFD6: gst_object_dispatch_properties_changed (gstobject.c:548)
==6849==    by 0x513536A: g_object_notify_by_pspec (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3200.3)
==6849==    by 0x4E8C583: gst_pad_set_caps (gstpad.c:2745)
==6849==    by 0x4E8DF7F: gst_pad_push_data (gstpad.c:4247)
==6849==    by 0x4E91A65: gst_pad_push (gstpad.c:4730)
==6849==    by 0x9276622: gst_qtdemux_decorate_and_push_buffer (qtdemux.c:3688)
==6849==    by 0x928A7BB: gst_qtdemux_loop (qtdemux.c:3767)
==6849==    by 0x4EB84EB: gst_task_func (gsttask.c:328)
==6849==  Address 0x8d549f4 is 516 bytes inside a block of size 329,110 free'd
==6849==    at 0x4C2A82E: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6849==    by 0x4E63079: gst_buffer_finalize (gstbuffer.c:207)
==6849==    by 0x4E876F0: gst_mini_object_unref (gstminiobject.c:376)
==6849==    by 0x928BD9F: gst_qtdemux_loop (gstbuffer.h:367)
==6849==    by 0x4EB84EB: gst_task_func (gsttask.c:328)
==6849==    by 0x53D8247: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3200.3)
==6849==    by 0x53D79E4: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3200.3)
==6849==    by 0x566AE99: start_thread (pthread_create.c:308)
==6849==

commit 1be98dfa4b5dcc9f23381b97d032c5bacc6f684e
Author: Tim-Philipp Müller <tim@centricular.net>
Date:   Fri Aug 3 23:55:47 2012 +0100

    qtdemux: fix invalid memory access with adpcm caps
    
    Copy codec_data buffer to put into adpcm caps instead of just making
    its data point to the current buffer, which is going to get unrefed'
    
    Fixes crashes when trying to serialise those caps, in gst-launch -v
    or programmatically.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=680726

Thanks! now gst-launch/my app not segfault anymore however myapp/gstreamer cannot decode the linked media (adpcmdec error out as you noted) while mplayer/ffplay can play the media, should I open a separate bug for this?

the linked media cause a memleak too

==21871== 240 bytes in 12 blocks are definitely lost in loss record 2,600 of 2,764
==21871==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21871==    by 0x5988A57: __vasprintf_chk (vasprintf_chk.c:82)
==21871==    by 0x53F0DBA: g_vasprintf (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3200.3)
==21871==    by 0x53D049C: g_strdup_vprintf (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3200.3)
==21871==    by 0x4E74357: _gst_element_error_printf (gstelement.c:1895)
==21871==    by 0xBA1B483: adpcmdec_handle_frame (adpcmdec.c:427)
==21871==    by 0x9D4E2C4: gst_audio_decoder_push_buffers (gstaudiodecoder.c:1044)
==21871==    by 0x9D4E71F: gst_audio_decoder_chain_forward (gstaudiodecoder.c:1146)
==21871==    by 0x9D50DD7: gst_audio_decoder_chain (gstaudiodecoder.c:1394)
==21871==    by 0x4E91B79: gst_pad_push (gstpad.c:4710)
==21871==    by 0x8DEFB06: gst_queue_loop (gstqueue.c:1156)
==21871==    by 0x4EB84EB: gst_task_func (gsttask.c:328)
==21871==    by 0x53D8247: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3200.3)
==21871==    by 0x53D79E4: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3200.3)
==21871==    by 0x566AE99: start_thread (pthread_create.c:308)

Yes, please file a separate bug for the adpcmdec issue and the leak.

Is the leak with gst-launch or your application? If your application, check that you're unreffing the error message on the bus and that you're freeing the GError and debug string properly.

the leak is with gst-launch too,

reported:

https://bugzilla.gnome.org/show_bug.cgi?id=681192

thanks
Nicola