After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 719811 - pulsesink: Leak of device_info in gst_pulsesink_sink_info_cb
pulsesink: Leak of device_info in gst_pulsesink_sink_info_cb
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: 1.2.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2013-12-03 23:19 UTC by Dirk-Jan C. Binnema
Modified: 2013-12-05 02:56 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Dirk-Jan C. Binnema 2013-12-03 23:19:30 UTC
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.
Comment 1 Olivier Crête 2013-12-04 21:27:22 UTC

commit dc782af133f1167b8b1ad77c3f30eda939098079
Author: Olivier Crête <>
Date:   Wed Dec 4 16:23:43 2013 -0500

    pulsesink: Free device_info in accepts caps
Comment 2 Olivier Crête 2013-12-04 21:29:25 UTC
Also pushed to 1.2.2 as a667681bf
Comment 3 Dirk-Jan C. Binnema 2013-12-05 02:56:36 UTC
Wow - that has been fixed amazingly fast -- thanks a lot!