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 669697 - shmsink blocking forever
shmsink blocking forever
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: 0.10.23
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-02-08 18:50 UTC by Guillaume Emont (guijemont)
Modified: 2012-02-09 18:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
shmsink: fix indefinite wait after adding a new fd to the poll set (1.38 KB, patch)
2012-02-08 21:24 UTC, Vincent Penquerc'h
committed Details | Review

Description Guillaume Emont (guijemont) 2012-02-08 18:50:32 UTC
I was trying to play with shmsink/shmsrc with the following simple gst-launch pipelines:

(1) gst-launch -v videotestsrc !  shmsink socket-path=/tmp/blah shm-size=1000000

(2) gst-launch shmsrc socket-path=/tmp/blah   ! "video/x-raw-yuv, format=(fourcc)YUY2, color-matrix=(string)sdtv, chroma-site=(string)mpeg2, width=(int)320, height=(int)240, framerate=(fraction)30/1" ! autovideosink

pipeline (2) is launched after (1), and the caps I put are the ones I see output by the first gst-launch.

Both pipelines block forever. In (2), shmsrc never seems to get any buffer (I think it never gets anything on the socket). In (1), pollthread_func() is blocked on gst_poll_wait(), after having gone through the continue added in a34108899ea5027be67e8a2c77c4ef67c093eb83.

Reverting that commit fixes the issue, and both pipelines work as expected, though I don't know if that's the best solution as I don't understand the concrete issue that it solves.
Comment 1 Vincent Penquerc'h 2012-02-08 21:24:28 UTC
This continue was added a while ago to fix an issue in a piece of software that I cannot test anymore, so here is what I think was happening, based on my recollection and re-reading the source for the shm plugin and GstPoll:

When a new fd is added to the poll object, a flag is set in GstPoll so that the active_fds array is updated on next call to _wait.

Calling other GstPoll routines between adding a new fd and _wait will cause the newly added fd to be ignored, as those routines do not check the flag and rebuild the active_fds array.

I can't recall the reason why I chose to ensure _wait was called after adding a new fd, instead of adding a rebuild flag check to every other _poll API. The interesting routines (eg, _can_read) seem to be pretty fast, assuming no lock contention, so that is an argument for not rebuilding here. The rebuilding code does not seem to be overly slow, so I'm not sure why it's not done directly instead of setting a flag, so causing a rebuild in every other GstPoll API would seem to go against that caching.

A possibility for the caching might be that calling select and others on an array of fds need that array to not change. However, calling that function is not done inside the lock, so this doesn't seem to be the reason (bar this being a bug).

So, a bit inconclusive on that choice. Maybe the typical use shows a lot of modifications of the fd array compared to _wait calls, which would warrant the rebuild delaying. I have not done such timing tests so that's just a guess.

Now, the issue here is that after the fd is added, a second call to _wait might block, preventing the remainder of the fnuction to signal the condition variable at the end. To fix this, I'm attaching a patch which returns on the 'continue' path if the wait would block. This is tested to fix the above pipeline set, and has a behavior more akin to the previous code.

If it works reliably for you, I'll push this.
If someone else that knows shmsrc/shmsink can shed some light on the caching performance reasons, please do :)
Comment 2 Vincent Penquerc'h 2012-02-08 21:24:44 UTC
Created attachment 207141 [details] [review]
shmsink: fix indefinite wait after adding a new fd to the poll set

If the second call to _wait blocks, we will not signal the condition
variable, so ensure that second call is not blocking.
See rationale and information in the linked bug:
Comment 3 Guillaume Emont (guijemont) 2012-02-09 15:32:27 UTC
The patch seems to work well for my case.
Thanks a lot!
Comment 4 Vincent Penquerc'h 2012-02-09 18:16:34 UTC
Thanks for the confirmation.

commit c83532553663218d7e89590afa574429bc1a3fe3
Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk>
Date:   Wed Feb 8 21:21:47 2012 +0000

    shmsink: fix indefinite wait after adding a new fd to the poll set
    
    If the second call to _wait blocks, we will not signal the condition
    variable, so ensure that second call is not blocking.
    See rationale and information in the linked bug:
    
    https://bugzilla.gnome.org/show_bug.cgi?id=669697