GNOME Bugzilla – Bug 664861
playbin2: File descriptor leak
Last modified: 2012-02-02 17:37:44 UTC
It appears that playbin2 is leaking fds in git master. This happens with pulseaudiosink but not pulsesink, but as far as I can tell, the actual bug is not actually in pulsesaudiosink. This is easy to demonstrate with gst-launch by sending it SIGUSR2 and then SIGUSR1 to bring the pipeline down to NULL and then playing again. Some results: gst-launch playbin2 uri=... audio-sink=pulsesink -- does not leak gst-launch playbin2 uri=... -- leaks one socket fd (pulseaudiosink is chosen since it has greater rank than pulsesink) gst-launch filesrc location=... ! mad ! pulseaudiosink -- does not leak
playbin2 doesn't even do anything with file descriptors. Is anything else leaked that shows up in valgrind?
I'll check again, but I don't recall finding anything. Could it be something that's holding an extra ref on the sink (only in the pulseaudiosink case)?
Could be but then the sink should appear in the valgrind output
Created attachment 202283 [details] dumb test program G_SLICE=always-malloc valgrind --leak-check=yes --suppressions=../gstreamer/common/gst.supp ./.libs/test-playbin2 file:///path/to/foo.flac file:///path/to/foo.mp3 ==18264== ==18264== HEAP SUMMARY: ==18264== in use at exit: 4,178,514 bytes in 27,608 blocks ==18264== total heap usage: 136,757 allocs, 109,149 frees, 80,313,958 bytes allocated ==18264== ==18264== Thread 1: ==18264== 248 bytes in 2 blocks are definitely lost in loss record 5,457 of 5,973 ==18264== at 0x4C2779D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==18264== by 0xB0445B4: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0) ==18264== by 0xB04467A: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0) ==18264== by 0xB04421A: xcb_connect_to_display_with_auth_info (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0) ==18264== by 0xA48FDED: pa_client_conf_from_x11 (in /usr/lib/x86_64-linux-gnu/libpulsecommon-1.1.so) ==18264== by 0xA00C9CE: pa_context_new_with_proplist (in /usr/lib/x86_64-linux-gnu/libpulse.so.0.13.5) ==18264== by 0x9BB19EF: gst_pulseringbuffer_open_device (pulsesink.c:493) ==18264== by 0x9DD2723: gst_ring_buffer_open_device (gstringbuffer.c:660) ==18264== by 0x9DE9634: gst_base_audio_sink_change_state (gstbaseaudiosink.c:2142) ==18264== by 0x9BB4DB0: gst_pulsesink_change_state (pulsesink.c:2976) ==18264== by 0x4E72B6B: gst_element_change_state (gstelement.c:2733) ==18264== by 0x4E734C1: gst_element_set_state_func (gstelement.c:2689) ==18264== ==18264== 544 (56 direct, 488 indirect) bytes in 1 blocks are definitely lost in loss record 5,593 of 5,973 ==18264== at 0x4C2779D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==18264== by 0x5D25392: g_malloc (gmem.c:164) ==18264== by 0x5D3BFE6: g_slice_alloc (gslice.c:842) ==18264== by 0x4E653EE: gst_caps_new_empty (gstcaps.c:165) ==18264== by 0x4E6560C: gst_caps_copy (gstcaps.c:310) ==18264== by 0x96FE1D3: gst_base_transform_find_transform (gstbasetransform.c:943) ==18264== by 0x9701FC8: gst_base_transform_setcaps (gstbasetransform.c:1244) ==18264== by 0x4E8AA1E: gst_pad_set_caps (gstpad.c:2727) ==18264== by 0x4E78C00: gst_proxy_pad_setcaps_default (gstghostpad.c:490) ==18264== by 0x8E6A5F4: gst_play_sink_convert_bin_sink_setcaps (gstplaysinkconvertbin.c:361) ==18264== by 0x4E8AA1E: gst_pad_set_caps (gstpad.c:2727) ==18264== by 0x4E8C4F6: gst_pad_push_data (gstpad.c:4244) ==18264== ==18264== LEAK SUMMARY: ==18264== definitely lost: 304 bytes in 3 blocks ==18264== indirectly lost: 488 bytes in 5 blocks ==18264== possibly lost: 0 bytes in 0 blocks ==18264== still reachable: 2,294,449 bytes in 7,085 blocks ==18264== suppressed: 1,883,273 bytes in 20,515 blocks ==18264== Reachable blocks (those to which a pointer was found) are not shown. ==18264== To see them, rerun with: --leak-check=full --show-reachable=yes
So, this looks more like a problem with pulsesink and that it doesn't destroy its (possibly shared) context sometimes. And an unrelated caps leak elsewhere
Any news on this?
Not sure why pulseaudio uses X, but this leak looks very very much like a bug in libxcb, also seen in https://bugzilla.gnome.org/show_bug.cgi?id=668894. Closing, then.
(In reply to comment #7) > Not sure why pulseaudio uses X, but this leak looks very very much like a bug Nice catch. Just for information's sake, X is used to get properties off the root window in order to figure out what PA server should be connected to.