It seems that gst_pulsesink_sink_info_cb is leaking memory; I found it in a bigger app (and seems to happen whenever the track changes), but it can be reproduced with gst-launch:

G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck --leak-check=full --leak-resolution=med  --track-origins=yes --num-callers=20 --log-file=vgdump gst-launch-1.0 playbin uri=file:///home/djcb/Music/song.ogg audio-sink=pulsesink

then, I get the following report:

==18429== 3,336 (72 direct, 3,264 indirect) bytes in 3 blocks are definitely lost in loss record 1,923 of 1,951
==18429==    at 0x4A0645D: malloc (vg_replace_malloc.c:291)
==18429==    by 0x3CECE4EE6E: g_malloc (gmem.c:104)
==18429==    by 0x3CECE64FAD: g_slice_alloc (gslice.c:1016)
==18429==    by 0x3CECE45345: g_list_prepend (glist.c:279)
==18429==    by 0x577F912: gst_pulsesink_sink_info_cb (pulsesink.c:2022)
==18429==    by 0x3F1861B55B: context_get_sink_info_callback (introspect.c:262)
==18429==    by 0x3F18237AFD: run_action (pdispatch.c:279)
==18429==    by 0x3F18237E9A: pa_pdispatch_run (pdispatch.c:331)
==18429==    by 0x3F1860F581: pstream_packet_callback (context.c:335)
==18429==    by 0x3F1823BE64: do_pstream_read_write (pstream.c:830)
==18429==    by 0x3F186240B3: pa_mainloop_dispatch (mainloop.c:656)
==18429==    by 0x3F18624489: pa_mainloop_iterate (mainloop.c:934)
==18429==    by 0x3F1862452F: pa_mainloop_run (mainloop.c:949)
==18429==    by 0x3F18632B35: thread (thread-mainloop.c:90)
==18429==    by 0x3F1824BBD7: internal_thread_func (thread-posix.c:83)
==18429==    by 0x398BC07F32: start_thread (pthread_create.c:309)
==18429==    by 0x398B0F4EAC: clone (clone.S:111)


which seems to point to in (gst_pulsesink_sink_info_cb):

    device_info->formats = g_list_prepend (device_info->formats,
        pa_format_info_copy (i->formats[j]));

which apparently is not freed in some case; of course valgrind reports are not 100% guarantees, but I actually can see the leak growing (in my bigger app, with track changes)

This is on Fedora 20.