After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 580373 - The GstQueue can't wait the signal, and then all the threads are blocked.
The GstQueue can't wait the signal, and then all the threads are blocked.
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.10.11
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-04-27 05:11 UTC by H.Y
Modified: 2009-08-10 03:27 UTC
See Also:
GNOME target: ---
GNOME version: 2.7/2.8


Attachments
gstqueue blocked log (188.07 KB, text/plain)
2009-04-27 05:15 UTC, H.Y
Details
gstqueue.c with debug info out (37.84 KB, text/plain)
2009-04-27 05:17 UTC, H.Y
Details
gstpad.c with debug info out (119.13 KB, text/plain)
2009-04-27 05:19 UTC, H.Y
Details

Description H.Y 2009-04-27 05:11:21 UTC
Please describe the problem:
The gst_queue_chain is still waiting, because the gst_queue_push_one sends the signal before the waiting in gst_queue_chain.

Steps to reproduce:
1. Playing video on arm device.
2. The playback will be blocked in serval minitues.
3. 


Actual results:
The playback is blocked, but the application is alive, it will be dead at any gst operation.

Expected results:
continue playing.

Does this happen every time?
about 90%.

Other information:
Comment 1 H.Y 2009-04-27 05:15:27 UTC
Created attachment 133391 [details]
gstqueue blocked log
Comment 2 H.Y 2009-04-27 05:17:35 UTC
Created attachment 133392 [details]
gstqueue.c with debug info out
Comment 3 H.Y 2009-04-27 05:19:35 UTC
Created attachment 133393 [details]
gstpad.c with debug info out
Comment 4 H.Y 2009-04-27 05:25:10 UTC
The application will be crashed when I use the GST_DEBUG with high level setting on gstreamer-0.10.11, right for low level, it maybe the serial is not strong enough or something else, so I add some debug info out manually in the gstqueue.c and gspad.c.
Comment 5 Wim Taymans 2009-04-27 08:57:06 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?
Comment 6 H.Y 2009-04-29 03:56:31 UTC
The components detail are as follows:
    gstreamer-0.10.11
    gst-plugins-base-0.10.11
    gst-plugins-good-0.10.5
    gst-plugins-ugly-0.10.6
    gst-plugins-bad-0.10.4
    gst-ffmpeg-0.10.2

    glib-2.8.6
    zlib-1.2.3
    libxml2-2.6.26

Yes, It is me running this on. For some reason I still use the 0.10.11, and I have buillt a 0.10.21 version for testing, it is also possible that I will upgrade it to the latest version. 

I will make a real debug log on the target device and support more info.

Thanks a lot!