Destroy/free the GstBus (in GStreamer) without leaking socket descriptors?

[Sebastian Dröge]

On Sat, 2023-03-25 at 00:52 +1100, Lance Luvaul via gstreamer-devel
wrote:
> Hi all, this is basically a repeat of my SO question
> at 
> https://stackoverflow.com/questions/75822100/destroy-free-the-gstbus-in-gstreamer-without-leaking-socket-descriptors
> , which I'll include below:
> 
> 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!)
> 
> 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:
> 
> [...]
> 
> 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
> https://gstreamer.freedesktop.org/documentation/application-development/basics/bus.html?gi-language=c
> , and I don't know what else to look for.
> 
> The problem described and the stack trace shown here
> https://gstreamer-bugs.narkive.com/j9vV002H/bug-683470-new-unix-socket-fd-leaks-and-memory-leaks-when-use-pipeline
> 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.
> 
> 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?

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).


-- 
Sebastian Dröge, Centricular Ltd · https://www.centricular.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20230324/4841bbd1/attachment.htm>