Dead lock when stopping a pipeline

[Thomas Scheuermann]

Hi all,

I've got a gstreamer pipeline which is running but sometimes when I try
to stop the pipeline I get a deadlock.

The pipeline gets an RTP stream over the network and decodes it with
vaapi. The output is sent to appsink. In the process sometimes run
several pipelines so the pipelines have to be started and stopped
without killing the program.

I have attached a backtrace and a dot file of the pipeline.

The GStreamer version which is used here is 1.10.2

Can there anybody help to debug this problem and interpret the backtrace?


Regards,

Thomas

This message is subject to the following terms and conditions: MAIL DISCLAIMER<http://www.barco.com/en/maildisclaimer>

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

[Yasushi SHOJI-2]

Hi,

On Fri, May 12, 2017 at 7:03 PM, Thomas Scheuermann <[hidden email]> wrote:
>
> I've got a gstreamer pipeline which is running but sometimes when I try
> to stop the pipeline I get a deadlock.

Here is my 2 cents.

First step is to make your pipeline small as possible.  To do that, try to avoid

using bins.

Also, if you are using appsink, you might wanna check your code first.

Good luck,

-- 

            yashi

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

[Nicolas Dufresne-5]

Le vendredi 12 mai 2017 à 12:03 +0200, Thomas Scheuermann a écrit :

> Hi all,
>
> I've got a gstreamer pipeline which is running but sometimes when I
> try
> to stop the pipeline I get a deadlock.
>
> The pipeline gets an RTP stream over the network and decodes it with
> vaapi. The output is sent to appsink. In the process sometimes run
> several pipelines so the pipelines have to be started and stopped
> without killing the program.
>
> I have attached a backtrace and a dot file of the pipeline.
>
> The GStreamer version which is used here is 1.10.2
>
> Can there anybody help to debug this problem and interpret the
> backtrace?

Initially I suspected the following issue:

  https://bugzilla.gnome.org/show_bug.cgi?id=783301

but the backtrace does not match. I'd look in gstreamer-vaapi if maybe
there is a missing ->unlock/unclock_stop() implementation that could
cause this. In general, with appsrc (and many other sources), a
workaround is to send a flush-start event to every sources before
setting them to NULL state. This is of course just a workaround, if you
could provide some runnable test to reproduce. Also, quick comparison
against 1.12 if you have a chances could help.

About the backtrace, basically it says that thread 5 is waiting for a
pad stream-lock (can't say which pad though). This is a pad between
appsrc and the vaapi decoder according thread 9. The problem is that
vaapi decoder didn't unblock it's operation when it went to READY.
Can't say why, but this sounds slightly familiar, hence me asking if
there is a missing unlock/unlock_stop(), or missing some code in the
state change handler (it depends on the base class a bit).

>
>
> Regards,
>
> Thomas
>
> This message is subject to the following terms and conditions: MAIL
> DISCLAIMER<http://www.barco.com/en/maildisclaimer>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

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