Pipeline freeze at preroll on embedded system

I just discovered that this pipeline works:
gst-launch-1.0 fakesrc is-live=true ! fakesink

Any ideas why is-live would make the pipeline work?

Post by Julian Scheel
Hi,
I am running a buildroot (uclibc) based system on raspberry pi. I just
updated gstreamer from 0.10 to 1.0.5. This introduced a very odd
problem. Every pipeline freezes in preroll state. Actually even a
gst-launch-1.0 fakesrc ! fakesink
causes the pipeline to freeze in preroll.
I have attached a logfile with GST_DEBUG=*:5 messages as well as a
picture of the created pipeline, which looks fine.
(gdb) thread apply all bt
#0 0xb6cabbbc in pthread_cond_wait () from /lib/libpthread.so.0
#1 0xb6d861a4 in g_cond_wait () from /usr/lib/libglib-2.0.so.0
at gstbasesink.c:2050
at gstbasesink.c:2140
#4 0xb6b9788c in gst_base_sink_do_sync
gstbasesink.c:2341
#5 0xb6b99fa8 in gst_base_sink_chain_unlocked
Unhandled dwarf expression opcode 0xfa>)
at gstbasesink.c:3189
#6 0xb6b9bad4 in gst_base_sink_chain_main (basesink=0x1fac050,
pad=<optimized out>, obj=0x1fb4048, is_list=0)
at gstbasesink.c:3323
#7 0xb6ec3e58 in gst_pad_chain_data_unchecked (data=0x1fb4048,
type=<optimized out>, pad=0x1faa170)
at gstpad.c:3654
at gstpad.c:3871
buffer=0x0) at gstpad.c:3974
#10 0xb6ba1250 in gst_base_src_loop (pad=0x1faa028) at gstbasesrc.c:2710
gsttask.c:316
#12 0xb6ef8250 in default_func (tdata=<optimized out>, pool=<optimized
out>) at gsttaskpool.c:70
#13 0xb6d6b488 in ?? () from /usr/lib/libglib-2.0.so.0
#14 0xb6d6b488 in ?? () from /usr/lib/libglib-2.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt
stack?)
#0 0xb6c88190 in read () from /lib/libc.so.0
#1 0xb6c88184 in read () from /lib/libc.so.0
#2 0xb6d85fa4 in g_mutex_lock () from /usr/lib/libglib-2.0.so.0
#3 0xb6d46b0c in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#4 0xb6d46f5c in ?? () from /usr/lib/libglib-2.0.so.0
Cannot access memory at address 0x0
#5 0xb6d46f5c in ?? () from /usr/lib/libglib-2.0.so.0
Cannot access memory at address 0x0
Backtrace stopped: previous frame identical to this frame (corrupt
stack?)
The same pipeline works perfectly fine with
gst-launch-0.10 fakesrc ! fakesink.
I did not change any build options between the gstreamer-0.10 and
gstreamer-1.0 build, nor did I change the toolchain or any toolchain
parameters.
Right now I am pretty clueless what's wrong. Any thoughs on what to
check would be more than welcome!
Regards,
Julian
_______________________________________________
gstreamer-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Julian Scheel

2013-01-20 11:46:22 UTC

Actually it does not really work. It just freezes at a later point
gst-launch-1.0 fakesrc is-live=true num-buffers=50 ! fakesink
will never terminate.

Post by Julian Scheel
gst-launch-1.0 fakesrc is-live=true ! fakesink
Any ideas why is-live would make the pipeline work?

_______________________________________________
gstreamer-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Sebastian Dröge

2013-01-20 12:06:44 UTC

Post by Julian Scheel
Actually it does not really work. It just freezes at a later point
gst-launch-1.0 fakesrc is-live=true num-buffers=50 ! fakesink
will never terminate.

Hi Julian,

as discussed on Friday already I believe that this is something broken
in the lower layers of your system already. You mentioned that the GLib
main loop for example already causes problems.

Did you check if someone else had similar problems running a custom RPi
distribution? Or do you know if someone is running a custom RPi
distribution without this problems, and checked if you built the system
the same way?

At least with Raspbian and Arch Linux on RPi this problems don't happen.

Julian Scheel

2013-01-20 13:17:50 UTC

Hi Sebastian,

Post by Julian Scheel
Actually it does not really work. It just freezes at a later point
gst-launch-1.0 fakesrc is-live=true num-buffers=50 ! fakesink
will never terminate.

as discussed on Friday already I believe that this is something broken
in the lower layers of your system already. You mentioned that the GLib
main loop for example already causes problems.

This was an assumption after looking into the backtraces of the error
case. But actually I think I was wrong about that. So the backtraces
seem fine - the main loop is just waiting for an event to happen.

Post by Sebastian DrÃ¶ge
Did you check if someone else had similar problems running a custom RPi
distribution? Or do you know if someone is running a custom RPi
distribution without this problems, and checked if you built the system
the same way?

I could find noone with similiar problems so far. But actually buildroot
is shipping gstreamer-0.10 and glib 2.30 by default, so it's unlikely
that many people have done gstreamer-1.0 build. I update to glib 2.32
and gstreamer-0.10, which works fine. Then I update gstreamer to 1.0
which does not work.
Right now I am tryint to update to glib 2.34, maybe that helps.

Post by Sebastian DrÃ¶ge
At least with Raspbian and Arch Linux on RPi this problems don't happen.

Raspbian and Arch don't use uclibc, do they? This might be an important
difference.

Regards,
Julian

Sebastian Dröge

2013-01-20 14:48:51 UTC

Post by Julian Scheel
Hi Sebastian,

Post by Julian Scheel
Actually it does not really work. It just freezes at a later point
gst-launch-1.0 fakesrc is-live=true num-buffers=50 ! fakesink
will never terminate.

as discussed on Friday already I believe that this is something broken
in the lower layers of your system already. You mentioned that the GLib
main loop for example already causes problems.

Hm right, that's what happens in your backtrace :)

Post by Sebastian DrÃ¶ge
At least with Raspbian and Arch Linux on RPi this problems don't happen.

Raspbian and Arch don't use uclibc, do they? This might be an important
difference.

They both use (e)glibc, yes. Maybe the pthread implementation of uclibc
has some behaviour differences compared to (e)glibc, which causes the
GLib GConds to not work as expected.

The GCond in question would usually be signalled when the state change
from PAUSED to PLAYING happens in basesink (or when
flushing/EOS/stepping). So what you could do is to check if

a) basesink is actually tried to be set from PAUSED to PLAYING (check if
the change_state function is called)
and b) if and when the GCond is signalled (while waiting? before? is
something else waiting at that time, in which case changing from SIGNAL
to BROADCAST should help, etc).

Julian Scheel

2013-01-20 20:57:22 UTC

Post by Julian Scheel
Hi Sebastian,

Post by Julian Scheel
Actually it does not really work. It just freezes at a later point
gst-launch-1.0 fakesrc is-live=true num-buffers=50 ! fakesink
will never terminate.

as discussed on Friday already I believe that this is something broken
in the lower layers of your system already. You mentioned that the GLib
main loop for example already causes problems.

Hm right, that's what happens in your backtrace :)

Post by Sebastian DrÃ¶ge
At least with Raspbian and Arch Linux on RPi this problems don't happen.

Raspbian and Arch don't use uclibc, do they? This might be an important
difference.

They both use (e)glibc, yes. Maybe the pthread implementation of uclibc
has some behaviour differences compared to (e)glibc, which causes the
GLib GConds to not work as expected.

Yes, that is what I think is most likely...

Post by Sebastian DrÃ¶ge
The GCond in question would usually be signalled when the state change
from PAUSED to PLAYING happens in basesink (or when
flushing/EOS/stepping). So what you could do is to check if
a) basesink is actually tried to be set from PAUSED to PLAYING (check if
the change_state function is called)

Actually I debugged this and the PAUSED to PLAYING transition is never happening. I can see that gstbasesrc change_state is called for GST_STATE_CHANGE_NULL_TO_READY as well as GST_STATE_CHANGE_READY_TO_PAUSED, but never for GST_STATE_CHANGE_PAUSED_TO_PLAYING.
So now the question is why this would not happen?
From where would that transition be initiated?

Post by Sebastian DrÃ¶ge
and b) if and when the GCond is signalled (while waiting? before? is
something else waiting at that time, in which case changing from SIGNAL
to BROADCAST should help, etc).

As PAUSED_TO_PLAYING transition is not happening the GCond will not be signalled, right?

Sebastian Dröge

2013-01-21 07:23:37 UTC

Julian Scheel

2013-01-21 08:43:41 UTC

Sebastian Dröge

2013-01-21 09:16:10 UTC

Julian Scheel

2013-01-22 09:32:19 UTC