Internal data flow problem for tcpserversink and sync-method=2 failing

[Tim-Philipp Müller]

On Tue, 2013-08-27 at 11:51 +0200, Peter Maersk-Moller wrote:

Hi Peter,


> Done, however it may not be as good documented as you may want it to
> be.
> 
> It's my first and there is a learning curve. Feel free to comment at
> https://bugzilla.gnome.org/show_bug.cgi?id=706872

That's great, thanks.


> For the request to debug and file a bug as described under here, I'm
> not quite there to do that yet. Thanks for explaining anyway.

It sounds like you can describe how to reproduce the issue (sender like
mpegtsmux ! tcpserversink, and then it happens when a client connects?).

That should be enough for someone to go and investigate. If you could
file another bug about that, that'd be great. If you can't debug it
yourself like I described, that's not a problem, it was just in case you
wanted to look into it some more yourself.

Cheers
 -Tim

> 
>         >         (gst-launch-1.0:7266): GStreamer-CRITICAL **:
>         >         gst_mini_object_ref: assertion `mini_object != NULL'
>         failed
>         >
>         >         (gst-launch-1.0:7266): GStreamer-CRITICAL **:
>         >         gst_caps_get_structure: assertion `GST_IS_CAPS
>         (caps)' failed
>         >
>         >         (gst-launch-1.0:7266): GStreamer-CRITICAL **:
>         >         gst_structure_has_field: assertion `structure !=
>         NULL' failed
>         
>         
>         These are pretty bad. Likely a refcount bug somewhere.
>         Criticals like
>         this usually mean that in other circumstances the code will
>         just crash,
>         but you got lucky this time.
>         
>         >         I tried to enable debug, but did not see anything
>         extra (which
>         >         is probably due to my lack of experience here)
>         
>         
>         Run gst-launch-1.0 in gdb with
>         
>           G_DEBUG=fatal_warnings gdb
>         --args /usr/bin/gst-launch-1.0 ....
>         
>         and reproduce it. It should then break at the first warning,
>         and you can
>         get a stack trace to see what buffer/caps/structure it
>         complains about,
>         and where in the code. You'll need debugging symbols in the
>         binaries for
>         that (there might be -dbg packages if you don't build from
>         source).
>         
>         Please file a bug about this, ideally with way to reproduce
>         and/or a
>         stack trace).