Python Gstreamer - Tearing down pipeline

[Matt Veenstra]

I have an ugly memory leak because I assumed GStreamer got cleaned up.
 Bad assumption on my part.

- I remove the bus signal and delete the bus.
- I set the pipeline to NULL and del the pipeline.

Question: Must I then release every element added?  Or are these
automatically cleaned up.

Thanks,
Matt
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Marko Mikkonen]

I'm developing a custom source plugin on Windows using MinGW and I'm
experiencing a crash at EOF event in GstBaseSink. My pipeline looks like
this:

my_source_plugin ! decodebin2 ! directsoundsink

My source plugin is essentially outputting an mp3 file. The sound comes
out without problems. At the end of file gstreamer goes to wait for the
playing to stop (afaik, on the basis that I've understood from debugging
these files). Then in gst_poll_wait, in the switch-case block
"GST_POLL_MODE_WINDOWS", WSAWaitForMultipleEvents is called with zero
event handle count and null event array pointer as arguments. The
function doesn't seem to like something and crashes. I can't debug any
further, because it's a Windows kernel function. I haven't found any
documentation which would say anything about the case when these
arguments are zero so I don't know if this is the real problem (but I
feel like it is).

I'm not sure what my plugin is doing wrong. Maybe it's sending a wrong
length of media or something, but I still think GstBaseSink should not
crash in this case.

The traceback of the crash point looks like this:

Thread [8] 0 (Suspended : Breakpoint)
Crash somewhere in here ->    WSAWaitForMultipleEvents()
     gst_poll_wait() at gstpoll.c:1 376 0x6b7016a7
     gst_system_clock_id_wait_jitter_unlocked() at gstsystemclock.c:619
0x6b712a91
     gst_clock_id_wait() at gstclock.c:467 0x6b6d4fe8
     gst_base_sink_wait_clock() at gstbasesink.c:2 129 0x6caca295
     gst_base_sink_wait_eos() at gstbasesink.c:2 324 0x6cad1283
     gst_base_audio_sink_drain() at gstbaseaudiosink.c:866 0x7068853e
     gst_base_audio_sink_event() at gstbaseaudiosink.c:894 0x7068deaf
     gst_base_sink_render_object() at gstbasesink.c:2 908 0x6caca790
     gst_base_sink_queue_object_unlocked() at gstbasesink.c:3 156
0x6cacfcae
     gst_base_sink_event() at gstbasesink.c:3 315 0x6cad0905
     gst_pad_send_event() at gstpad.c:5 365 0x6b6f645d
     gst_pad_push_event() at gstpad.c:5 217 0x6b6f6a15
     gst_base_transform_sink_event() at gstbasetransform.c:1 956 0x6cadb27a
     gst_pad_send_event() at gstpad.c:5 365 0x6b6f645d
     gst_pad_push_event() at gstpad.c:5 217 0x6b6f6a15
     gst_pad_send_event() at gstpad.c:5 365 0x6b6f645d
     gst_pad_push_event() at gstpad.c:5 217 0x6b6f6a15
     gst_pad_send_event() at gstpad.c:5 365 0x6b6f645d
     gst_pad_push_event() at gstpad.c:5 217 0x6b6f6a15
     gst_pad_send_event() at gstpad.c:5 365 0x6b6f645d
<...more frames...>

The last function, WSAWaitForMultipleEvents, is called like this:

         wait_ret = WSAWaitForMultipleEvents (set->active_events->len,
             (HANDLE *) set->active_events->data, FALSE, t, FALSE);

Here set->active_events->len and set->active_events->data are both null.
Variable t has some value (about 100-300, it varies).

I have compiled everything myself and the gstreamer package is
gstreamer-0.10.32. I don't know how else to clarify this situation. You
can email me and ask for the values of variables in any of the functions
in the stack, if you need them.

The question is of course: What is the problem and how to fix it?

-Marko
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Mailing List SVR]

Il giorno gio, 03/03/2011 alle 10.10 -0800, Matt Veenstra ha scritto:
> I have an ugly memory leak because I assumed GStreamer got cleaned up.
>  Bad assumption on my part.
>
> - I remove the bus signal and delete the bus.
> - I set the pipeline to NULL and del the pipeline.
>
> Question: Must I then release every element added?

No they are automatically cleaned up, however if you keep a reference
somewhere in your app to the pipeline or to some elements the memory is
not freed I did the same mistake in my app,

Nicola

>   Or are these
> automatically cleaned up.
>
> Thanks,
> Matt
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Marko Mikkonen]

PLEASE, I need SOMEONE to take a look at this. This looks to me like a
bug in GStreamer itself or GstBaseSink or GstAudioBaseSink.

I had to recompile everything again to get rid of optimization, because
it scrambled the debugger at last stages before the call to
WSAWaitForMultipleEvents. What I found out was that in gst_poll_wait in
gstpoll.c, the test "if (TEST_REBUILD (set))" on the line 1241 fails. If
I comment out the test, the event gets set and my pipeline works:

/*    if (TEST_REBUILD (set)) {*/
       g_mutex_lock (set->lock);
#ifndef G_OS_WIN32
       g_array_set_size (set->active_fds, set->fds->len);
       memcpy (set->active_fds->data, set->fds->data,
           set->fds->len * sizeof (struct pollfd));
#else
       if (!gst_poll_prepare_winsock_active_sets (set))      /*If I
comment out the if-clause, the execution reaches this line.*/
         goto winsock_error;
#endif
       g_mutex_unlock (set->lock);
/*    }*/

This is probably a bad hack and &(set)->rebuild that is tested in
if-clause should be set earlier(???). But where? What's the purpose of
&(set)->rebuild? Could someone PLEASE take a look at this! I'm a total
n00b with GStreamer and I have next to no idea what this code does.

-Marko


6.3.2011 17:20, Marko Mikkonen kirjoitti:

> I'm developing a custom source plugin on Windows using MinGW and I'm
> experiencing a crash at EOF event in GstBaseSink. My pipeline looks
> like this:
>
> my_source_plugin ! decodebin2 ! directsoundsink
>
> My source plugin is essentially outputting an mp3 file. The sound
> comes out without problems. At the end of file gstreamer goes to wait
> for the playing to stop (afaik, on the basis that I've understood from
> debugging these files). Then in gst_poll_wait, in the switch-case
> block "GST_POLL_MODE_WINDOWS", WSAWaitForMultipleEvents is called with
> zero event handle count and null event array pointer as arguments. The
> function doesn't seem to like something and crashes. I can't debug any
> further, because it's a Windows kernel function. I haven't found any
> documentation which would say anything about the case when these
> arguments are zero so I don't know if this is the real problem (but I
> feel like it is).
>
> I'm not sure what my plugin is doing wrong. Maybe it's sending a wrong
> length of media or something, but I still think GstBaseSink should not
> crash in this case.
>
> The traceback of the crash point looks like this:
>
> Thread [8] 0 (Suspended : Breakpoint)
> Crash somewhere in here ->    WSAWaitForMultipleEvents()
>     gst_poll_wait() at gstpoll.c:1 376 0x6b7016a7
>     gst_system_clock_id_wait_jitter_unlocked() at gstsystemclock.c:619
> 0x6b712a91
>     gst_clock_id_wait() at gstclock.c:467 0x6b6d4fe8
>     gst_base_sink_wait_clock() at gstbasesink.c:2 129 0x6caca295
>     gst_base_sink_wait_eos() at gstbasesink.c:2 324 0x6cad1283
>     gst_base_audio_sink_drain() at gstbaseaudiosink.c:866 0x7068853e
>     gst_base_audio_sink_event() at gstbaseaudiosink.c:894 0x7068deaf
>     gst_base_sink_render_object() at gstbasesink.c:2 908 0x6caca790
>     gst_base_sink_queue_object_unlocked() at gstbasesink.c:3 156
> 0x6cacfcae
>     gst_base_sink_event() at gstbasesink.c:3 315 0x6cad0905
>     gst_pad_send_event() at gstpad.c:5 365 0x6b6f645d
>     gst_pad_push_event() at gstpad.c:5 217 0x6b6f6a15
>     gst_base_transform_sink_event() at gstbasetransform.c:1 956
> 0x6cadb27a
>     gst_pad_send_event() at gstpad.c:5 365 0x6b6f645d
>     gst_pad_push_event() at gstpad.c:5 217 0x6b6f6a15
>     gst_pad_send_event() at gstpad.c:5 365 0x6b6f645d
>     gst_pad_push_event() at gstpad.c:5 217 0x6b6f6a15
>     gst_pad_send_event() at gstpad.c:5 365 0x6b6f645d
>     gst_pad_push_event() at gstpad.c:5 217 0x6b6f6a15
>     gst_pad_send_event() at gstpad.c:5 365 0x6b6f645d
> <...more frames...>
>
> The last function, WSAWaitForMultipleEvents, is called like this:
>
>         wait_ret = WSAWaitForMultipleEvents (set->active_events->len,
>             (HANDLE *) set->active_events->data, FALSE, t, FALSE);
>
> Here set->active_events->len and set->active_events->data are both
> null. Variable t has some value (about 100-300, it varies).
>
> I have compiled everything myself and the gstreamer package is
> gstreamer-0.10.32. I don't know how else to clarify this situation.
> You can email me and ask for the values of variables in any of the
> functions in the stack, if you need them.
>
> The question is of course: What is the problem and how to fix it?
>
> -Marko
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel