[gst-devel] Re: [gst-cvs] company gstreamer: gstreamer/gst/

Benjamin Otte in7y118 at public.uni-hamburg.de
Thu Apr 17 10:06:11 CEST 2003


We might want to make a g_return_val_if_fail out of it, though I am
strongly against continuing a program that definitely did something
wrong. And I needed close to 3 hours to find out that because of allowing
this, state changes of threads inside threads go through nicely and
deadlock. That sucks quite a bit because you tend to
not find it inside lots of debugging output.

I found out that it breaks the player. You cannot start playing anything
without that assertion stopping the program.
So either we have to fix the thread implementation or we have to loosen
this check. I definitely vote for 1)
An element that claims a successful state change without changing its
state can only be very broken.

Benjamin

On Thu, 17 Apr 2003, David I. Lehn wrote:

> * Benjamin Otte <company at users.sourceforge.net> [20030417 09:59]:
> > --- gstelement.c	13 Apr 2003 03:04:26 -0000	1.194
> > +++ gstelement.c	17 Apr 2003 13:52:41 -0000	1.195
> > @@ -2261,15 +2261,8 @@
> >        case GST_STATE_SUCCESS:
> >          /* Last thing we do is verify that a successful state change really
> >           * did change the state... */
> > -        if (GST_STATE (element) != curpending) {
> > -          GST_DEBUG_ELEMENT (GST_CAT_STATES, element,
> > -			     "element claimed state-change success,"
> > -			     "but state didn't change %s, %s <-> %s",
> > -                     	     gst_element_state_get_name (GST_STATE (element)),
> > -                     	     gst_element_state_get_name (GST_STATE_PENDING (element)),
> > -                     	     gst_element_state_get_name (curpending));
> > -          return GST_STATE_FAILURE;
> > -	}
> > +        /* if it did not, this is an error - fix the element that does this */
> > +        g_assert (GST_STATE (element) == curpending);
> >          break;
>
> Would it be useful to do both on failure?  Print out the debug info then
> have a hard death?  Seems like a return val if fail call, rather than
> assert, would work just as well here too.
>
> -dave
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>





More information about the gstreamer-devel mailing list