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

GStreamer (bugzilla.gnome.org) bugzilla-daemon at bugzilla.gnome.org
Mon Apr 27 01:57:08 PDT 2009

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:

  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

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

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.

More information about the Gstreamer-bugs mailing list