Socket file descriptor leaks with GstBus

[Duzy Chan]

Hi Tim,

This issue can be duplicated in one of my test case, which can be launched
by in the project https://github.com/duzy/gst-switch:

    $ make test-composite-mode

Or:

    $ make TESTARGS="--print-debug-messages" test-composite-mode

Or (this will produce tests/test-switch-server-valgrind.log):

    $ make TESTARGS="--valgrind" test-composite-mode

The "test-composite-mode" repeatedly send request to the gst-switch-server
which will cause the server indirectly recreate the pipelines.

Duzy




On Wed, Feb 6, 2013 at 5:42 PM, Tim-Philipp Müller <t.i.m at zen.co.uk> wrote:

> On Wed, 2013-02-06 at 10:01 +0800, Duzy Chan wrote:
>
> Hi,
>
> have you tried making a minimal stand-alone test case for this?
>
> Cheers
>  -Tim
>
> > I'm using GStreamer for a AV switch app. Which will recreate the
> > pipelines looks like as following listing repeatedly:
> >
> >
> >         intervideosrc name=source_a channel=composite_a
> >         intervideosrc name=source_b channel=composite_b
> >         videomixer name=compose
> >         source_b. ! video/x-raw,width=100,height=56
> >             ! queue2 ! compose.sink_1
> >         source_a. ! video/x-raw,width=100,height=56
> >             ! queue2 ! compose.sink_0
> >         compose. ! video/x-raw,width=100,height=56
> >             ! queue2 ! gdppay ! tcpserversink name=out port=3001
> >
> > But it turns out there're socket file descriptors leaking until "Too
> > many open files" issued and be killed the app. The error looks like:
> >
> >
> > (gst-switch-srv:1709): GLib-ERROR **: Creating pipes for GWakeup: Too
> > many open files
> >
> >
> > And my code used to recreate the pipelines is gst_worker_reset which
> > is at
> > https://github.com/duzy/gst-switch/blob/master/tools/gstworker.c#L597as it's looking like:
> >
> >
> >
> >   worker->pipeline = workerclass->create_pipeline (worker);
> >
> >
> >   if (!worker->pipeline)
> >
> >
> >     goto error_create_pipeline;
> >
> >
> >
> >
> >   gst_pipeline_set_auto_flush_bus (GST_PIPELINE (worker->pipeline),
> > FALSE);
> >
> >
> >
> >
> >   worker->bus = gst_pipeline_get_bus (GST_PIPELINE
> > (worker->pipeline));
> >
> >
> >   if (!worker->bus)
> >
> >
> >     goto error_get_bus;
> >
> >
> >
> >
> >   worker->watch = gst_bus_add_watch (worker->bus,
> >
> >
> >       (GstBusFunc) gst_worker_message, worker);
> >
> >
> >   if (!worker->watch)
> >
> >
> >     goto error_add_watch;
> >
> >
> >
> >
> >   if (workerclass->prepare && !workerclass->prepare (worker))
> >
> >
> >     goto error_prepare;
> >
> >
> >
> >
> > By hacking into tcpserversink, I found that the tcpserversink will
> > emit a client-socket-removed signal and requiring it's client code to
> > manually close the socket, and I've already done it by
> >
> >
> >   g_signal_connect (sink, "client-socket-removed",
> >
> >
> >       G_CALLBACK (output_client_socket_removed), w);
> >
> >
> > And:
> >
> >
> >
> > static void
> >
> >
> > output_client_socket_removed (GstElement *element,
> >
> >
> >     GSocket *socket, GstComposite *composite)
> >
> >
> > {
> >   g_return_if_fail (G_IS_SOCKET (socket));
> >
> >
> >   g_socket_close (socket, NULL);
> >
> >
> > }
> >
> >
> > But it don't solve the socket file descriptor leaks problem. While
> > doing track-fds using valgrind, I got these:
> >
> >
> > ==5605== FILE DESCRIPTORS: 822 open at exit.
> > ......
> > ==5605==
> >
> > ==5605== Open AF_UNIX socket 821: <unknown>
> > ==5605==    at 0x5D13F8A: socketpair (syscall-template.S:82)
> > ==5605==    by 0x4EA2227: gst_poll_new (gstpoll.c:569)
> > ==5605==    by 0x4EA22FD: gst_poll_new_timer (gstpoll.c:630)
> > ==5605==    by 0x4E6AA84: gst_bus_constructed (gstbus.c:152)
> > ==5605==    by 0x54A1122: g_object_newv (gobject.c:1747)
> > ==5605==    by 0x4E6B105: gst_bus_new (gstbus.c:286)
> > ==5605==    by 0x4E9B6A5: gst_pipeline_init (gstpipeline.c:210)
> > ==5605==    by 0x54BBDDE: g_type_create_instance (gtype.c:1912)
> > ==5605==    by 0x549F6B7: g_object_constructor (gobject.c:1855)
> > ==5605==    by 0x54A0CB0: g_object_newv (gobject.c:1719)
> > ==5605==    by 0x4E7D44D: gst_element_factory_create
> > (gstelementfactory.c:377)
> > ==5605==    by 0x4E7D60E: gst_element_factory_make
> > (gstelementfactory.c:446)
> > ==5605==    by 0x4EDF184: priv_gst_parse_launch (grammar.y:965)
> > ==5605==    by 0x4ED639C: gst_parse_launch_full (gstparse.c:324)
> > ==5605==    by 0x405714: gst_worker_create_pipeline (gstworker.c:181)
> > ==5605==    by 0x4052B4: gst_worker_prepare_unsafe (gstworker.c:611)
> > ==5605==    by 0x40560F: gst_worker_reset (gstworker.c:708)
> > ==5605==    by 0x40C91D: gst_composite_apply_parameters
> > (gstcomposite.c:332)
> > ==5605==    by 0x40CD17: gst_composite_null (gstcomposite.c:540)
> > ==5605==    by 0x4063D8: gst_worker_message (gstworker.c:438)
> > ......
> >
> >
> >
> >
> > Do you guys have any suggestion on this? Please help. Is it a bug?
> >
> >
> > Best Regards Sincerely
> > Duzy Chan
> >
> >
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130206/f34cd189/attachment-0001.html>