GNOME Bugzilla – Bug 734358
Deadlock streaming an HD video
Last modified: 2018-02-28 07:07:12 UTC
While streaming an HD video from, after about 30 seconds to a minute, I get this deadlock.
+ Trace 233934
I'm fairly sure that the code in: https://git.gnome.org/browse/rygel/tree/src/media-engines/gstreamer/rygel-gst-sink.vala#n80 isn't thread-safe and can deadlock.
rygel-0.23.2-1.fc21.x86_64 glib2-2.41.2-2.fc21.x86_64
Is there a way to reproduce this? I've never seen this.
I've never seen this either but I can't really argue with Bastien: checking this.frozen outside the mutex lock seems like an obvious thread safety violation, right?
yep
(In reply to comment #2) > Is there a way to reproduce this? I've never seen this. On my laptop, I'm sharing an SMB folder coming from my NAS. I'm reading the video from a set-top box. Transcoding is disabled.
*** Bug 736135 has been marked as a duplicate of this bug. ***
Debarshi hit the same bug in a different path. Could this be related to glib 2.41 mutex changes? " I am hitting this when trying to test the code for: https://wiki.gnome.org/ThreePointThirteen/Features/BrowseDMSPhotos I have rygel running on a second laptop serving a folder full of images. It shows up as /com/intel/dLeynaServer/server/1 on my first laptop that is running dleyna-server. I call SearchObjects on its org.gnome.UPnP.MediaContainer2 interface with these arguments: 'Type = "image.photo"', 0, 0, ['URLs'] This gives me a bunch of URLs (eg., http://192.168.0.16:43669/MediaExport/i/YzlkMjc0NDFhZjA2MGVjNjBmZDc4OTI0NTFiYzc4ZmU%3D.JPG) , but when I try to open one of them in a browser either it loads part of the image or nothing at all. At this point if I call Rescan and then GetServers on the /com/intel/dLeynaServer object, then it does not show any servers. I have: dleyna-server-0.4.0 gupnp-0.20.12 rygel-0.22.3 libsoup-2.46.0 "
Created attachment 285727 [details] [review] engine-gst: Guard read access to critical section Untested, because I am having trouble building rygel on Fedora - gupnp-av-1.0 vs GUPnPAV-1.0, etc..
Attachment 285727 [details] pushed as b3066f3 - engine-gst: Guard read access to critical section
Unfortunately, when I was testing this patch yesterday (I had modified the C sources in the tarball to the same effect), I kept having the same deadlock. I think there is more to this bug than the unguarded read access.
Is that a gdb trace issue or are those really two different mutexes in g_cond_wait and g_mutex_lock?
Created attachment 285905 [details] [review] engine-gst: Guard read access to critical section Same thing, but this time in the thaw function. I have not had a chance to test this because I noticed this while skimming through the sources once more. I really should read it more carefully the first time.
The patch makes sense, but as I completely fail to reproduce this, I can't really test whether it fixes the issue
Is this fixed now?
ping
It's not possible to reproduce the problem because rygel seems to have regressed. Using rygel-0.26.0-1.fc22.x86_64 And adding: /run/user/1000/gvfs/smb-share:server=diskstation.local,share=videos/New/ to my rygel.conf throws those errors: (rygel:13669): MediaExport-WARNING **: Failed to get file info for smb://diskstation.local/videos/New/: Operation not supported by backend Because rygel doesn't support non-local files, but seems to want to handle URIs nonetheless. Totem works around that by doing: path = g_file_get_path (file); uri = g_filename_to_uri (path, NULL, NULL); which gives you a URI, but going through fuse, instead of completely failing to read the files.
that's odd, the code responsible for that hasn't changed between 0.24 and 0.26
The warnings are coming from g_file_query_info_async
comment 17 might be fixed now - can you check whether this is still happening?
Assumed fixed