<div dir="ltr"><div>Hi all, this is basically a repeat of my SO question at <a href="https://stackoverflow.com/questions/75822100/destroy-free-the-gstbus-in-gstreamer-without-leaking-socket-descriptors">https://stackoverflow.com/questions/75822100/destroy-free-the-gstbus-in-gstreamer-without-leaking-socket-descriptors</a>, which I'll include below:</div><div><br></div>I've inherited a server application that responds to incoming requests by building a GStreamer filter graph to return a copy of a short 12 second segment of a much longer video file before finally tearing down / destroying the graph.  (I am unfamiliar with GStreamer BTW, so apologies if any of the questions below cover basic stuff!)<br><br>There is a socket leak somewhere in this code: I can see /proc/<pid>/fd filling up with socket entries.  valgrind tells me these are not INET sockets but rather UNIX (Unix domain) sockets, which GStreamer creates via the `socketpair()` system call.  An example of one of the stack traces from valgrind is below:<br><br>    ==1== Open AF_UNIX socket 6: <unknown><br>    ==1==    at 0x6A40C8A: socketpair (syscall-template.S:78)<br>    ==1==    by 0x53554C9: gst_poll_new (gstpoll.c:692)<br>    ==1==    by 0x535558D: gst_poll_new_timer (gstpoll.c:751)<br>    ==1==    by 0x530D998: gst_bus_constructed (gstbus.c:156)<br>    ==1==    by 0x561A8AF: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)<br>    ==1==    by 0x561BE94: g_object_new_with_properties (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)<br>    ==1==    by 0x561C910: g_object_new (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)<br>    ==1==    by 0x530E071: gst_bus_new (gstbus.c:285)<br>    ==1==    by 0x534E634: gst_pipeline_init (gstpipeline.c:228)<br>    ==1==    by 0x56399E4: g_type_create_instance (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)<br>    ==1==    by 0x561A6F7: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)<br>    ==1==    by 0x561C56F: g_object_new_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)<br><br>A quick Google search tells me socket leaks in GStreamer client code are fairly common and are often caused by improper handling of the message bus.  My code *does* get a handle to the bus via `gst_element_get_bus()`, then calls `gst_bus_post()` and `gst_bus_timed_pop()` on it before calling `gst_object_unref()` on it during cleanup.<br><br>The code is summarized below:<br><br>    m_pipeline = ges_pipeline_new();<br>    m_bus = gst_element_get_bus(GST_ELEMENT(m_pipeline));<br>    ...<br>    gst_bus_post(m_bus, gst_message_new_application(GST_OBJECT_CAST(m_pipeline), gst_structure_new_empty(_DO_SEEK_MSG)));<br>    ...<br>    GstMessage* msg = gst_bus_timed_pop(m_bus, timeoutMS*GST_MSECOND);<br>    if (msg) {<br>        DoSomethingWithMessage(msg);<br>        gst_message_unref(msg);<br>    }<br>    ...<br>    if (m_bus) gst_object_unref(m_bus);<br>    if (m_pipeline) {<br>        gst_element_set_state((GstElement*)m_pipeline, GST_STATE_NULL);<br>        gst_object_unref(m_pipeline);<br>    }<br><br>As a hack, I've duplicated the `gst_object_unref(m_bus)` call and the socket leak has vanished... well, mostly: there's other leaks, but the socket leaks have dried up enormously.  I know this isn't the proper way to deal with the bus, but it tells me that the bus object has a dangling reference to it somewhere.  However, all calls that interact with m_bus are included in the code above, which look (more or less) like the example at <a href="https://gstreamer.freedesktop.org/documentation/application-development/basics/bus.html?gi-language=c">https://gstreamer.freedesktop.org/documentation/application-development/basics/bus.html?gi-language=c</a>, and I don't know what else to look for.<div><br></div><div>The problem described and the stack trace shown here <a href="https://gstreamer-bugs.narkive.com/j9vV002H/bug-683470-new-unix-socket-fd-leaks-and-memory-leaks-when-use-pipeline" target="_blank">https://gstreamer-bugs.narkive.com/j9vV002H/bug-683470-new-unix-socket-fd-leaks-and-memory-leaks-when-use-pipeline</a> are almost identical to mine but, unlike them, I don't use `id = gst_bus_add_watch()` so can't use `g_source_remove(id)` to free the bus.</div><div><br></div><div>What is going on in the code that would cause the socket leak?  Any suggestions of what to look for?  Any general debugging tips for tracking down stray/unhandled references in GStreamer code?<br></div><div><br></div><div>Many thanks,</div><div>Lance</div><div><br></div></div>