[gstreamer-bugs] [Bug 580373] The GstQueue can't wait the signal, and then all the threads are blocked.

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=580373

  GStreamer | gstreamer (core) | Ver: 0.10.11

Wim Taymans changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wim.taymans at gmail.com
             Status|UNCONFIRMED                 |NEEDINFO




------- Comment #5 from Wim Taymans  2009-04-27 08:57 UTC -------
0.10.11 is almost 2.5 years old...

Your analysis is unlikely true, the chain and push_one functions both take
locks and check the status of the queue before blocking, even if push_one were
to signal before the chain function was entered, there would be no problem
because the chain function would see that there is space in the queue and not
block.

Blocking queues are usually either:
 - some error happened downstream (usually wrong-state) that stops the pushing
part of the queue
 - some sink blocking a long time on the buffer, overflowing the queue.

If you say GST_DEBUG crashes, is this related to the 64bit printf functions
that were buggy in older glib versions perhaps?

We need more info, were are you running this on? why such an old version? can't
you make a real debug log? Can you make a bull backtrace of when things are
locked?


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=580373.