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

[Lance Luvaul]

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:

    ==1== Open AF_UNIX socket 6: <unknown>
    ==1==    at 0x6A40C8A: socketpair (syscall-template.S:78)
    ==1==    by 0x53554C9: gst_poll_new (gstpoll.c:692)
    ==1==    by 0x535558D: gst_poll_new_timer (gstpoll.c:751)
    ==1==    by 0x530D998: gst_bus_constructed (gstbus.c:156)
    ==1==    by 0x561A8AF: ??? (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
    ==1==    by 0x561BE94: g_object_new_with_properties (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
    ==1==    by 0x561C910: g_object_new (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
    ==1==    by 0x530E071: gst_bus_new (gstbus.c:285)
    ==1==    by 0x534E634: gst_pipeline_init (gstpipeline.c:228)
    ==1==    by 0x56399E4: g_type_create_instance (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
    ==1==    by 0x561A6F7: ??? (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
    ==1==    by 0x561C56F: g_object_new_valist (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)

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.

The code is summarized below:

    m_pipeline = ges_pipeline_new();
    m_bus = gst_element_get_bus(GST_ELEMENT(m_pipeline));
    ...
    gst_bus_post(m_bus,
gst_message_new_application(GST_OBJECT_CAST(m_pipeline),
gst_structure_new_empty(_DO_SEEK_MSG)));
    ...
    GstMessage* msg = gst_bus_timed_pop(m_bus, timeoutMS*GST_MSECOND);
    if (msg) {
        DoSomethingWithMessage(msg);
        gst_message_unref(msg);
    }
    ...
    if (m_bus) gst_object_unref(m_bus);
    if (m_pipeline) {
        gst_element_set_state((GstElement*)m_pipeline, GST_STATE_NULL);
        gst_object_unref(m_pipeline);
    }

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?

Many thanks,
Lance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20230325/3756a2cc/attachment.htm>