Force stopping a gstreamer pipeline

[Thomas Scheuermann]

Hello,

is there a way to force the stopping of a gstreamer pipeline?
We have here a process running with several pipelines which are started
and stopped dynamically. Sometimes it happens that when I set the state
of the pipeline to GST_STATE_NULL (gst_element_set_state(_pipeline,
GST_STATE_NULL);) this call never comes back.
What can I do in this situation?
I use gstreamer 1.8.1

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

[Sebastian Dröge-3]

On Fr, 2016-06-03 at 10:51 +0200, Thomas Scheuermann wrote:

> Hello,
>
> is there a way to force the stopping of a gstreamer pipeline?
> We have here a process running with several pipelines which are
> started
> and stopped dynamically. Sometimes it happens that when I set the
> state
> of the pipeline to GST_STATE_NULL (gst_element_set_state(_pipeline,
> GST_STATE_NULL);) this call never comes back.
> What can I do in this situation?
> I use gstreamer 1.8.1

The only way for this to not return is if there is a bug in one of the
elements used by the pipeline, and e.g. the thread is deadlocking.
There's not really anything you can do at that point other than fixing
that bug, or isolating the GStreamer pipeline code in separate threads
(or even processes that can just be killed if needed) so that
deadlocking threads are not taking down the application.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le 3 juin 2016 5:06 AM, "Thomas Scheuermann" <[hidden email]> a écrit :
>
> Hello,
>
> is there a way to force the stopping of a gstreamer pipeline?
> We have here a process running with several pipelines which are started
> and stopped dynamically. Sometimes it happens that when I set the state
> of the pipeline to GST_STATE_NULL (gst_element_set_state(_pipeline,
> GST_STATE_NULL);) this call never comes back.
> What can I do in this situation?
> I use gstreamer 1.8.1
>

This is a deadlock. It should not happen unless you are doing something wrong in your application, or if you have hit a big in GStreamer. You may want to share a full backtrace.

Nicolas

> 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

[amitchawla]

Hi Sebastian

Could you please look at the following thread and let me know ...

http://gstreamer-devel.966125.n4.nabble.com/Unable-to-change-state-GST-STATE-PLAYING-tp4677811.html

Thanks for your help.

Amit

[Sebastian Dröge-3]

On So, 2016-06-05 at 22:32 -0700, amitchawla wrote:
> Hi Sebastian
>
> Could you please look at the following thread and let me know ...
>
> http://gstreamer-devel.966125.n4.nabble.com/Unable-to-change-state-GS
> T-STATE-PLAYING-tp4677811.html
>
> Thanks for your help.

Don't reply to arbitrary threads and pointing someone personally at
some other thread, asking for a reply.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Thomas Scheuermann]

Hi,

Am 03.06.2016 um 12:59 schrieb Nicolas Dufresne:

Le 3 juin 2016 5:06 AM, "Thomas Scheuermann" <[hidden email][hidden email]> a écrit :
>
> Hello,
>
> is there a way to force the stopping of a gstreamer pipeline?
> We have here a process running with several pipelines which are started
> and stopped dynamically. Sometimes it happens that when I set the state
> of the pipeline to GST_STATE_NULL (gst_element_set_state(_pipeline,
> GST_STATE_NULL);) this call never comes back.
> What can I do in this situation?
> I use gstreamer 1.8.1
>

This is a deadlock. It should not happen unless you are doing something wrong in your application, or if you have hit a big in GStreamer. You may want to share a full backtrace.

Nicolas

Here is a sample code of a deadlock. I think, it is in jackaudiosink.
If you restart the jack daemon while the pipeline is playing, the pipeline can't be stopped anymore.

/*
 * reproducer for deadlock
 *
 * gcc -o deadlock deadlock.c -g `pkg-config --libs --cflags gstreamer-1.0` -Wall
 */
#include <stdio.h>
#include <gst/gst.h>

int main(int argc, char **argv)
{
    GstElement *pipeline;
    GstElement *audiosrc;
    GstElement *audiofilter;
    GstElement *audiosink;
    GstCaps *caps;

    gst_init(&argc, &argv);

    pipeline = gst_pipeline_new("pipeline");
    g_assert(pipeline);

    audiosrc = gst_element_factory_make("audiotestsrc", "audiotestsrc");
    g_assert(audiosrc);

    audiofilter = gst_element_factory_make("capsfilter", "capsfilter");
    g_assert(audiofilter);
    caps = gst_caps_new_simple("audio/x-raw", "channels", G_TYPE_INT, 2, NULL);
    g_object_set(G_OBJECT(audiofilter), "caps",caps, NULL);
    gst_caps_unref(caps);

    audiosink = gst_element_factory_make("jackaudiosink", "jackaudiosink");
    g_assert(audiosink);
    g_object_set(G_OBJECT(audiosink), "client-name", "test", NULL);

    g_print("Adding elements\n");
    gst_bin_add_many(GST_BIN(pipeline), audiosrc, audiofilter, audiosink, NULL);

    gst_element_link_many(audiosrc, audiofilter, audiosink, NULL);

    g_print("Set pipeline state to playing\n");
    gst_element_set_state(pipeline, GST_STATE_PLAYING);

    g_print("Restart jack daemon and press enter\n");
    getchar();

    g_print("Set pipeline state to null\n");
    gst_element_set_state(pipeline, GST_STATE_NULL);
    g_print("Unref pipeline\n");
    gst_object_unref(pipeline);

    return 0;
}


This message is subject to the following terms and conditions: MAIL DISCLAIMER
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Mo, 2016-06-06 at 16:45 +0200, Thomas Scheuermann wrote:

> Hi,
>
> Am 03.06.2016 um 12:59 schrieb Nicolas Dufresne:
> > Le 3 juin 2016 5:06 AM, "Thomas Scheuermann" <[hidden email]
> > > a écrit :
> > >
> > > Hello,
> > >
> > > is there a way to force the stopping of a gstreamer pipeline?
> > > We have here a process running with several pipelines which are
> > started
> > > and stopped dynamically. Sometimes it happens that when I set the
> > state
> > > of the pipeline to GST_STATE_NULL
> > (gst_element_set_state(_pipeline,
> > > GST_STATE_NULL);) this call never comes back.
> > > What can I do in this situation?
> > > I use gstreamer 1.8.1
> > >
> > This is a deadlock. It should not happen unless you are doing
> > something wrong in your application, or if you have hit a big in
> > GStreamer. You may want to share a full backtrace.
> > Nicolas
>  Here is a sample code of a deadlock. I think, it is in
> jackaudiosink.
> If you restart the jack daemon while the pipeline is playing, the
> pipeline can't be stopped anymore.

Can you get a backtrace of all threads when it deadlocks?

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Thomas Scheuermann]

Am 06.06.2016 um 16:57 schrieb Sebastian Dröge:

On Mo, 2016-06-06 at 16:45 +0200, Thomas Scheuermann wrote:

Hi,

Here is a sample code of a deadlock. I think, it is in
jackaudiosink.
If you restart the jack daemon while the pipeline is playing, the
pipeline can't be stopped anymore.

Can you get a backtrace of all threads when it deadlocks?

Here is the backtrace:

(gdb) thread apply all bt

Thread 4 (Thread 0x7f6d87201700 (LWP 4362)):
#0  0x00007f6d8527b08f in [hidden email] () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f6d83282d3c in  () at /usr/lib/x86_64-linux-gnu/libjack.so.0
#2  0x00007f6d83279ea8 in  () at /usr/lib/x86_64-linux-gnu/libjack.so.0
#3  0x00007f6d83281d20 in  () at /usr/lib/x86_64-linux-gnu/libjack.so.0
#4  0x00007f6d852770a4 in start_thread (arg=0x7f6d87201700) at pthread_create.c:309
#5  0x00007f6d8587587d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 3 (Thread 0x7f6d870ea700 (LWP 4364)):
#0  0x00007f6d8527d130 in sem_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_timedwait.S:101
#1  0x00007f6d8328285e in  () at /usr/lib/x86_64-linux-gnu/libjack.so.0
#2  0x00007f6d8326af9d in  () at /usr/lib/x86_64-linux-gnu/libjack.so.0
#3  0x00007f6d8326a11f in  () at /usr/lib/x86_64-linux-gnu/libjack.so.0
#4  0x00007f6d83269468 in  () at /usr/lib/x86_64-linux-gnu/libjack.so.0
#5  0x00007f6d83281d20 in  () at /usr/lib/x86_64-linux-gnu/libjack.so.0
#6  0x00007f6d852770a4 in start_thread (arg=0x7f6d870ea700) at pthread_create.c:309
#7  0x00007f6d8587587d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 2 (Thread 0x7f6d82aec700 (LWP 4365)):
#0  0x00007f6d85871809 in syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x00007f6d8611b0bf in g_cond_wait (cond=0xc4e268, mutex=0xc4e228) at /home/barco/glib2.0-2.46.0/./glib/gthread-posix.c:1397
#2  0x00007f6d83d74123 in wait_segment (buf=0xc4e210 [GstJackAudioSinkRingBuffer]) at gstaudioringbuffer.c:1319
#3  0x00007f6d83d746b8 in default_commit (buf=0xc4e210 [GstJackAudioSinkRingBuffer], sample=0x80, data=0x3ce <error: Cannot access memory at address 0x3ce>, in_samples=1023, out_samples=1023, accum=0xc4e210)
    at gstaudioringbuffer.c:1553
#4  0x00007f6d83d8ebfa in gst_audio_base_sink_render (bsink=0xc3f680 [GstJackAudioSink], buf=<optimized out>) at gstaudiobasesink.c:2162
#5  0x00007f6d86942242 in gst_base_sink_chain_unlocked (basesink=0xc3f680 [GstJackAudioSink], obj=0x7f6d7001b500, is_list=974, is_list@entry=0, pad=<optimized out>) at gstbasesink.c:3532
#6  0x00007f6d86943484 in gst_base_sink_chain_main (basesink=0xc3f680 [GstJackAudioSink], pad=<optimized out>, obj=0x7f6d7001b500, is_list=0) at gstbasesink.c:3655
#7  0x00007f6d8665caea in gst_pad_push_data (data=<optimized out>, type=<optimized out>, pad=<optimized out>) at gstpad.c:4176
#8  0x00007f6d8665caea in gst_pad_push_data (pad=0xc3a4f0 [GstPad], type=2257860000, data=0x7f6d7001b500) at gstpad.c:4428
#9  0x00007f6d866647de in gst_pad_push (pad=0xc3a4f0 [GstPad], buffer=0x7f6d7001b500) at gstpad.c:4547
#10 0x00007f6d8694d22d in gst_base_transform_chain (pad=0xc4e270, parent=0xc40230 [GstCapsFilter], buffer=0x0) at gstbasetransform.c:2369
#11 0x00007f6d8665caea in gst_pad_push_data (data=<optimized out>, type=<optimized out>, pad=<optimized out>) at gstpad.c:4176
#12 0x00007f6d8665caea in gst_pad_push_data (pad=0xc3a070 [GstPad], type=2257899664, data=0x7f6d7001b500) at gstpad.c:4428
#13 0x00007f6d866647de in gst_pad_push (pad=0xc3a070 [GstPad], buffer=0x7f6d7001b500) at gstpad.c:4547
#14 0x00007f6d86948e85 in gst_base_src_loop (pad=0xc3a070 [GstPad]) at gstbasesrc.c:2850
#15 0x00007f6d8668efc1 in gst_task_func (task=0xc5d050 [GstTask]) at gsttask.c:332
#16 0x00007f6d860fdda8 in g_thread_pool_thread_proxy (data=<optimized out>) at /home/barco/glib2.0-2.46.0/./glib/gthreadpool.c:307
#17 0x00007f6d860fd415 in g_thread_proxy (data=0xc4d400) at /home/barco/glib2.0-2.46.0/./glib/gthread.c:778
#18 0x00007f6d852770a4 in start_thread (arg=0x7f6d82aec700) at pthread_create.c:309
#19 0x00007f6d8587587d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 1 (Thread 0x7f6d87203700 (LWP 4361)):
#0  0x00007f6d85868e0d in read () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f6d858023a0 in _IO_new_file_underflow (fp=0x7f6d85b334e0 <_IO_2_1_stdin_>) at fileops.c:605
#2  0x00007f6d858031ce in __GI__IO_default_uflow (fp=0x7f6d85b334e0 <_IO_2_1_stdin_>) at genops.c:435
#3  0x00007f6d857febaa in getchar () at getchar.c:37
#4  0x0000000000400dbe in main (argc=1, argv=0x7ffcecaf0068) at deadlock.c:43

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

This message is subject to the following terms and conditions: MAIL DISCLAIMER
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Mo, 2016-06-06 at 17:13 +0200, Thomas Scheuermann wrote:

>
>
> Am 06.06.2016 um 16:57 schrieb Sebastian Dröge:
> > On Mo, 2016-06-06 at 16:45 +0200, Thomas Scheuermann wrote:
> > > Hi,
> > >
> > > Here is a sample code of a deadlock. I think, it is in
> > > jackaudiosink.
> > > If you restart the jack daemon while the pipeline is playing, the
> > > pipeline can't be stopped anymore.
> > Can you get a backtrace of all threads when it deadlocks?
>  Here is the backtrace:
>
> (gdb) thread apply all bt
>
> [...]

That backtrace is still before the state is set to NULL. Can you get
one a bit later? :)

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Thomas Scheuermann]

Am 06.06.2016 um 17:49 schrieb Sebastian Dröge:
>   [...]
> That backtrace is still before the state is set to NULL. Can you get
> one a bit later? :)
>
Sorry. Here it comes

(gdb) thread apply all bt

Thread 3 (Thread 0x7f6d87201700 (LWP 4362)):
#0  0x00007f6d8527b08f in pthread_cond_wait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f6d83282d3c in  () at /usr/lib/x86_64-linux-gnu/libjack.so.0
#2  0x00007f6d83279ea8 in  () at /usr/lib/x86_64-linux-gnu/libjack.so.0
#3  0x00007f6d83281d20 in  () at /usr/lib/x86_64-linux-gnu/libjack.so.0
#4  0x00007f6d852770a4 in start_thread (arg=0x7f6d87201700) at
pthread_create.c:309
#5  0x00007f6d8587587d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 2 (Thread 0x7f6d82aec700 (LWP 4365)):
#0  0x00007f6d85871809 in syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x00007f6d8611b0bf in g_cond_wait (cond=0xc5d0b0, mutex=0xc5d068) at
/home/barco/glib2.0-2.46.0/./glib/gthread-posix.c:1397
#2  0x00007f6d8668f15d in gst_task_func (task=0xc5d050 [GstTask]) at
gsttask.c:317
#3  0x00007f6d860fdda8 in g_thread_pool_thread_proxy (data=<optimized
out>) at /home/barco/glib2.0-2.46.0/./glib/gthreadpool.c:307
#4  0x00007f6d860fd415 in g_thread_proxy (data=0xc4d400) at
/home/barco/glib2.0-2.46.0/./glib/gthread.c:778
#5  0x00007f6d852770a4 in start_thread (arg=0x7f6d82aec700) at
pthread_create.c:309
#6  0x00007f6d8587587d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 1 (Thread 0x7f6d87203700 (LWP 4361)):
#0  0x00007f6d85871809 in syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x00007f6d8611b0bf in g_cond_wait (cond=0xc3ea90, mutex=0xc3ea88) at
/home/barco/glib2.0-2.46.0/./glib/gthread-posix.c:1397
#2  0x00007f6d834a8640 in gst_jack_audio_client_set_active
(client=0xc4db00, active=0) at gstjackaudioclient.c:604
#3  0x00007f6d834a5ea4 in gst_jack_ring_buffer_release (buf=0xc4e210
[GstJackAudioSinkRingBuffer]) at gstjackaudiosink.c:544
#4  0x00007f6d83d759b8 in gst_audio_ring_buffer_release (buf=0xc4e210
[GstJackAudioSinkRingBuffer]) at gstaudioringbuffer.c:693
#5  0x00007f6d83d93108 in gst_audio_base_sink_change_state
(element=0xc3f680 [GstJackAudioSink],
transition=GST_STATE_CHANGE_PAUSED_TO_READY) at gstaudiobasesink.c:2507
#6  0x00007f6d8664737e in gst_element_change_state (element=0xc3f680
[GstJackAudioSink], transition=GST_STATE_CHANGE_PAUSED_TO_READY) at
gstelement.c:2648
#7  0x00007f6d86647afa in gst_element_set_state_func (element=0xc3f680
[GstJackAudioSink], state=GST_STATE_READY) at gstelement.c:2602
#8  0x00007f6d8662645d in gst_bin_change_state_func (next=<optimized
out>, current=<optimized out>, start_time=<optimized out>,
base_time=<optimized out>, element=<optimized out>, bin=<optimized out>)
at gstbin.c:2414
#9  0x00007f6d8662645d in gst_bin_change_state_func (element=0x0,
transition=128) at gstbin.c:2756
#10 0x00007f6d8664737e in gst_element_change_state (element=0xc340e0
[GstPipeline], transition=GST_STATE_CHANGE_PAUSED_TO_READY) at
gstelement.c:2648
#11 0x00007f6d86647637 in gst_element_change_state (element=0xc340e0
[GstPipeline], transition=GST_STATE_CHANGE_PLAYING_TO_PAUSED) at
gstelement.c:2687
#12 0x00007f6d86647afa in gst_element_set_state_func (element=0xc340e0
[GstPipeline], state=GST_STATE_NULL) at gstelement.c:2602
#13 0x0000000000400dde in main (argc=1, argv=0x7ffcecaf0068) at
deadlock.c:46


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

[Thomas Scheuermann]

Should I create a ticket for this bug?

Am 07.06.2016 um 08:48 schrieb Thomas Scheuermann:

>
>
> Am 06.06.2016 um 17:49 schrieb Sebastian Dröge:
>>   [...]
>> That backtrace is still before the state is set to NULL. Can you get
>> one a bit later? :)
>>
> Sorry. Here it comes
>
> (gdb) thread apply all bt
>
> Thread 3 (Thread 0x7f6d87201700 (LWP 4362)):
> #0  0x00007f6d8527b08f in pthread_cond_wait@@GLIBC_2.3.2 () at
> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
> #1  0x00007f6d83282d3c in  () at /usr/lib/x86_64-linux-gnu/libjack.so.0
> #2  0x00007f6d83279ea8 in  () at /usr/lib/x86_64-linux-gnu/libjack.so.0
> #3  0x00007f6d83281d20 in  () at /usr/lib/x86_64-linux-gnu/libjack.so.0
> #4  0x00007f6d852770a4 in start_thread (arg=0x7f6d87201700) at
> pthread_create.c:309
> #5  0x00007f6d8587587d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
>
> Thread 2 (Thread 0x7f6d82aec700 (LWP 4365)):
> #0  0x00007f6d85871809 in syscall () at
> ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
> #1  0x00007f6d8611b0bf in g_cond_wait (cond=0xc5d0b0, mutex=0xc5d068) at
> /home/barco/glib2.0-2.46.0/./glib/gthread-posix.c:1397
> #2  0x00007f6d8668f15d in gst_task_func (task=0xc5d050 [GstTask]) at
> gsttask.c:317
> #3  0x00007f6d860fdda8 in g_thread_pool_thread_proxy (data=<optimized
> out>) at /home/barco/glib2.0-2.46.0/./glib/gthreadpool.c:307
> #4  0x00007f6d860fd415 in g_thread_proxy (data=0xc4d400) at
> /home/barco/glib2.0-2.46.0/./glib/gthread.c:778
> #5  0x00007f6d852770a4 in start_thread (arg=0x7f6d82aec700) at
> pthread_create.c:309
> #6  0x00007f6d8587587d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
>
> Thread 1 (Thread 0x7f6d87203700 (LWP 4361)):
> #0  0x00007f6d85871809 in syscall () at
> ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
> #1  0x00007f6d8611b0bf in g_cond_wait (cond=0xc3ea90, mutex=0xc3ea88) at
> /home/barco/glib2.0-2.46.0/./glib/gthread-posix.c:1397
> #2  0x00007f6d834a8640 in gst_jack_audio_client_set_active
> (client=0xc4db00, active=0) at gstjackaudioclient.c:604
> #3  0x00007f6d834a5ea4 in gst_jack_ring_buffer_release (buf=0xc4e210
> [GstJackAudioSinkRingBuffer]) at gstjackaudiosink.c:544
> #4  0x00007f6d83d759b8 in gst_audio_ring_buffer_release (buf=0xc4e210
> [GstJackAudioSinkRingBuffer]) at gstaudioringbuffer.c:693
> #5  0x00007f6d83d93108 in gst_audio_base_sink_change_state
> (element=0xc3f680 [GstJackAudioSink],
> transition=GST_STATE_CHANGE_PAUSED_TO_READY) at gstaudiobasesink.c:2507
> #6  0x00007f6d8664737e in gst_element_change_state (element=0xc3f680
> [GstJackAudioSink], transition=GST_STATE_CHANGE_PAUSED_TO_READY) at
> gstelement.c:2648
> #7  0x00007f6d86647afa in gst_element_set_state_func (element=0xc3f680
> [GstJackAudioSink], state=GST_STATE_READY) at gstelement.c:2602
> #8  0x00007f6d8662645d in gst_bin_change_state_func (next=<optimized
> out>, current=<optimized out>, start_time=<optimized out>,
> base_time=<optimized out>, element=<optimized out>, bin=<optimized out>)
> at gstbin.c:2414
> #9  0x00007f6d8662645d in gst_bin_change_state_func (element=0x0,
> transition=128) at gstbin.c:2756
> #10 0x00007f6d8664737e in gst_element_change_state (element=0xc340e0
> [GstPipeline], transition=GST_STATE_CHANGE_PAUSED_TO_READY) at
> gstelement.c:2648
> #11 0x00007f6d86647637 in gst_element_change_state (element=0xc340e0
> [GstPipeline], transition=GST_STATE_CHANGE_PLAYING_TO_PAUSED) at
> gstelement.c:2687
> #12 0x00007f6d86647afa in gst_element_set_state_func (element=0xc340e0
> [GstPipeline], state=GST_STATE_NULL) at gstelement.c:2602
> #13 0x0000000000400dde in main (argc=1, argv=0x7ffcecaf0068) at
> deadlock.c:46
>
>
> 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

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

[Sebastian Dröge-3]

On Do, 2016-06-09 at 14:49 +0200, Thomas Scheuermann wrote:
> Should I create a ticket for this bug?

Yes, please include the backtrace and the testcase there. Looks like a
bug in the jack plugin during shutdown. It waits forever for its own
condition variable.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Tim Müller]

On Thu, 2016-06-09 at 16:29 +0300, Sebastian Dröge wrote:

> On Do, 2016-06-09 at 14:49 +0200, Thomas Scheuermann wrote:
> > Should I create a ticket for this bug?
>
> Yes, please include the backtrace and the testcase there. Looks like
> a
> bug in the jack plugin during shutdown. It waits forever for its own
> condition variable.
> 

Looks like bug https://bugzilla.gnome.org/show_bug.cgi?id=747275

Cheers
 -Tim

--

Tim Müller, Centricular Ltd - http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Thomas Scheuermann]

Am 09.06.2016 um 16:03 schrieb Tim Müller:
> Looks like bug https://bugzilla.gnome.org/show_bug.cgi?id=747275
Last week I've added a patch to this ticket which prevents GStreamer
from blocking if the connection to the jack server is lost. Is there
anything else I have to do that the patch gets integrated?
> Cheers
>   -Tim
>
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

[saepia]

My experience with JACK is that when the JACK daemon deadlocks due to failure of any client (or one of JACK internal bugs) the result in GStreamer may be also a deadlock as it waits indefinitely for processing.

In practice I found JACK not suitable for anything serious.

Marcin

2016-06-06 16:45 GMT+02:00 Thomas Scheuermann <[hidden email]>:

Hi,

Am 03.06.2016 um 12:59 schrieb Nicolas Dufresne:

Le 3 juin 2016 5:06 AM, "Thomas Scheuermann" <[hidden email][hidden email]> a écrit :
>
> Hello,
>
> is there a way to force the stopping of a gstreamer pipeline?
> We have here a process running with several pipelines which are started
> and stopped dynamically. Sometimes it happens that when I set the state
> of the pipeline to GST_STATE_NULL (gst_element_set_state(_pipeline,
> GST_STATE_NULL);) this call never comes back.
> What can I do in this situation?
> I use gstreamer 1.8.1
>

This is a deadlock. It should not happen unless you are doing something wrong in your application, or if you have hit a big in GStreamer. You may want to share a full backtrace.

Nicolas

Here is a sample code of a deadlock. I think, it is in jackaudiosink.
If you restart the jack daemon while the pipeline is playing, the pipeline can't be stopped anymore.

/*
 * reproducer for deadlock
 *
 * gcc -o deadlock deadlock.c -g `pkg-config --libs --cflags gstreamer-1.0` -Wall
 */
#include <stdio.h>
#include <gst/gst.h>

int main(int argc, char **argv)
{
    GstElement *pipeline;
    GstElement *audiosrc;
    GstElement *audiofilter;
    GstElement *audiosink;
    GstCaps *caps;

    gst_init(&argc, &argv);

    pipeline = gst_pipeline_new("pipeline");
    g_assert(pipeline);

    audiosrc = gst_element_factory_make("audiotestsrc", "audiotestsrc");
    g_assert(audiosrc);

    audiofilter = gst_element_factory_make("capsfilter", "capsfilter");
    g_assert(audiofilter);
    caps = gst_caps_new_simple("audio/x-raw", "channels", G_TYPE_INT, 2, NULL);
    g_object_set(G_OBJECT(audiofilter), "caps",caps, NULL);
    gst_caps_unref(caps);

    audiosink = gst_element_factory_make("jackaudiosink", "jackaudiosink");
    g_assert(audiosink);
    g_object_set(G_OBJECT(audiosink), "client-name", "test", NULL);

    g_print("Adding elements\n");
    gst_bin_add_many(GST_BIN(pipeline), audiosrc, audiofilter, audiosink, NULL);

    gst_element_link_many(audiosrc, audiofilter, audiosink, NULL);

    g_print("Set pipeline state to playing\n");
    gst_element_set_state(pipeline, GST_STATE_PLAYING);

    g_print("Restart jack daemon and press enter\n");
    getchar();

    g_print("Set pipeline state to null\n");
    gst_element_set_state(pipeline, GST_STATE_NULL);
    g_print("Unref pipeline\n");
    gst_object_unref(pipeline);

    return 0;
}


This message is subject to the following terms and conditions: MAIL DISCLAIMER

_______________________________________________
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

[Sebastian Dröge-3]

On Do, 2016-07-07 at 15:21 +0200, Thomas Scheuermann wrote:
>
> Am 09.06.2016 um 16:03 schrieb Tim Müller:
> > Looks like bug https://bugzilla.gnome.org/show_bug.cgi?id=747275
> Last week I've added a patch to this ticket which prevents GStreamer
> from blocking if the connection to the jack server is lost. Is there
> anything else I have to do that the patch gets integrated?

I've just reviewed the patch shortly, there's still an open question.

--

Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel