Socket file descriptor leaks with GstBus

[Duzy Chan]

I'm trying to make the stand alone test case, and it turns out I did got
something interesting:

https://github.com/duzy/gst-switch/blob/master/tests/test_fd_leaks.c


It looks like the GST_STATE_CHANGE_READY_TO_NULL message was not issued
while I was stopping the worker (setting the pipeline to GST_STATE_NULL).
Yet the state did changed into NULL (according to gst_element_get_state).
I'm wondering if I was doing something wrong.

But when I enabled this line:

// see:
https://github.com/duzy/gst-switch/blob/master/tools/gstworker.c#L629

gst_pipeline_set_auto_flush_bus (GST_PIPELINE (worker->pipeline), FALSE);


I got the expected GST_STATE_CHANGE_READY_TO_NULL state change message.

Do you guys have some ideas on this? I assume I should have missed
something.


On Thu, Feb 7, 2013 at 9:12 AM, Duzy Chan <geek at duzy.info> wrote:

>
>
>
> On Thu, Feb 7, 2013 at 6:17 AM, David Schleef <ds at schleef.org> wrote:
>
>> On Wed, Feb 06, 2013 at 06:40:08PM +0800, Duzy Chan wrote:
>> > On Wed, Feb 6, 2013 at 6:22 PM, Tim-Philipp Müller <t.i.m at zen.co.uk>
>> wrote:
>> >
>> > > Yes, I did check that out and did look at it, but I'm afraid I don't
>> > > really have time to look at all that in detail, hence the request for
>> > > something stand-alone and minimal. If it's an issue with pipeline
>> > > creation / GstBus / watch usage, it shouldn't be too hard to
>> re-create.
>> > >
>> >
>> > I would like to do a bit effort to make a stand alone minimal test case
>> of
>> > the GstBus usage, and see if we can duplicate the same issue to help to
>> > find out the reason.
>> >
>>
>> The first thing you should check is that you are properly cleaning
>> up all your objects.  If you leak a pipeline, object, or bus, you'll
>> end up with multiple copies of intervideosrc around, which will
>> use file descriptors.
>>
>
> I hacked a bit into intervideosrc, but it looks like the inter elements
> are all memory based, which I think should be in-process available, without
> allocating a file descriptor, all memory based utilities: list, buffer,
> mutex.
>
> Now I'm thinking that if there're any messages which holding the
> references of the pipeline, and when I unref-ed the pipeline, somehow
> caused cycling-referencing (my guess). Because in per cycle reset of the
> pipeline, I did g_source_remove the watch, gst_object_unref the bus, null
> and gst_object_unref the pipeline.
>
> I tried to make my reset function (say gst_worker_reset) none-operation
> (which I commented out all, leaving a "result = TRUE"), and the file
> descriptor leaks gone.
>
> So I'm guessing it's somehow getting cycling-referencing or I did forgot
> to unref something.
>
> I'll spend some time to play around the stand-alone test code to try to
> duplicate the execution flow in minimal. And also check further.
>
>
>>
>>
>>
>> David
>>
>> _______________________________________________
>> 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/20130207/15e37184/attachment.html>