<html><head></head><body><div>On Sat, 2023-03-25 at 00:52 +1100, Lance Luvaul via gstreamer-devel wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><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>[...]<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?</div></div></blockquote><div><br></div><div>Can you create an issue in GitLab with the whole, minimal code to reproduce the problem? There doesn't seem to be anything wrong in the part that you pasted into the mail so there's either a bug elsewhere in your code, or indeed a leak in GStreamer (which seems unlikely as this would've been noticed, but who knows).</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"></blockquote><div><br></div><div><span><pre>-- <br></pre><div><div><span style="font-family: Calibri, sans-serif; font-size: 14.666667px;">Sebastian Dröge, Centricular Ltd · </span><a href="https://www.centricular.com/" title="Click to open https://www.centricular.com/" style="color: rgb(0, 0, 238); font-family: Calibri, sans-serif; font-size: 14.666667px;">https://www.centricular.com</a></div></div></span></div></body></html>