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 166250 - [PATCH] [queue] When two threads are connected with queue, state change fails
[PATCH] [queue] When two threads are connected with queue, state change fails
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.8.8
Other All
: High critical
: 0.8.10
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-02-04 08:13 UTC by Mark Kretschmann
Modified: 2005-02-08 13:51 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
testcase program (10.00 KB, application/x-compressed-tar)
2005-02-04 08:18 UTC, Mark Kretschmann
  Details
proposed fix (965 bytes, patch)
2005-02-08 10:42 UTC, Ronald Bultje
none Details | Review

Description Mark Kretschmann 2005-02-04 08:13:07 UTC
Steps to reproduce:
1. Start my testcase application. 
2.  
3.  
 

Stack trace:


Other information:
Comment 1 Mark Kretschmann 2005-02-04 08:16:59 UTC
More verbose description: 
 
You have two threads, they are connected with a queue, let's call them input 
and output thread. Now you change the state of the input thread to PAUSED 
while the output thread is PLAYING; Then change it back to PLAYING. Result: 
Scheduler crash. 
 
Workaround: The queue element must be paused before changing state of the 
input thread. Not nice. 
 
Comment 2 Mark Kretschmann 2005-02-04 08:18:01 UTC
Created attachment 36968 [details]
testcase program
Comment 3 Ronald Bultje 2005-02-08 10:33:54 UTC
The pipeline is correctly interrupted, but queue sets an infinite interrupted
state. The output threads, which continues playing, will always stay interrupted
and return interrupt events. This is a bug in the queue element. I'm not sure
what the expected behaviour is, really. Queue would either hang indefinately
while the input is paused (which is fine, I think), or it could not allow gets
while no input is active (which is counterintuitive for a buffering element).

That's the only bug I see here. Apart from that, all's fine. I can try to fix
queue sometime soon.
Comment 4 Ronald Bultje 2005-02-08 10:42:19 UTC
Created attachment 37154 [details] [review]
proposed fix

Reset interrupt state after interrupt (_release_locks()) is handled. Makes this
testcase work.
Comment 5 Ronald Bultje 2005-02-08 13:51:26 UTC
Applied.