GNOME Bugzilla – Bug 783675
queue2: Deadlock in Queue2 when music streaming plays long time.
Last modified: 2018-11-03 12:41:41 UTC
A deadlock occurred while accessing one variable in two threads. This is sometimes issue. One thread sets the "downstream_may_block" value. Compares this value with another thread and executes g_cond_wait(). Deadlock occurs at this point.
Created attachment 353596 [details] [review] add the mutex to prevent access at the same time.
Review of attachment 353596 [details] [review]: ::: plugins/elements/gstqueue2.c @@ +2967,2 @@ g_atomic_int_set (&queue->downstream_may_block, 0); + GST_QUEUE2_MUTEX_UNLOCK (queue); This is atomically set, so no mutex is needed as long as the other usage of that variable is correctly done with atomic operations too. Is it not?
I tested it according to your comment, but it still takes a deadlock. I know there is a process that supports atomic, but if it does not support our system seems to need a lock, what do you think? Do you know how to know a process that supports atomic?
(In reply to Suhwang Kim from comment #3) > I tested it according to your comment, but it still takes a deadlock. > I know there is a process that supports atomic, but if it does not support > our system seems to need a lock, what do you think? > Do you know how to know a process that supports atomic? All architectures on which GLib builds have support for atomic instructions. GLib won't build, and you will have to take action if it wasn't the case.
I tested as solmo's comment. (Just using unlock) And Got the log i attached. I inserted some logs for debugging. You can grep using the following keywords "dbg". As you can see the log, Thread(0x44f630) request streaming data from server. But It is going to be locking g_cond_wait at (0:00:01.210808084). A lock is held until the seek command is encountered.(0:01:50.297251427) If you keep playing continuously, there will be a lock forever maybe.:) The Thread(0x44f630) doesn't request streaming data. I think that this problem is related with value of "downstream_may_block". This thread(0x2f4bb0) set the downstream_may_block. And the other thread(0x44f630) get the downstream_may_block when some query was received. So I try to prevent this value(downstream_may_block) with mutex lock and unlock. Do you have any other idea?
Created attachment 353641 [details] This is debug log.
Can you provide a way to reproduce it? And do you think any of the usage of atomic operations for downstream_may_block is not thread-safe (and does using a mutex really solve it for you)?
I just play the music long time trough the DLNA It's not always issue. This issue occasionally occurred. The results I have tested so far seem to use of mutex locks.
flac audio streaming can reproduce well with DLNA.
My patch is not the right way to solve this issue. The problem was reproduced when I applied my patch. I think some module has stopped processing the query, so what do you think?
We would need to have a backtrace to analyze what the issue is. But my guess is that's it's indeed a problem happening at a higher level.
Suhwang, can you provide a stream that reproduces this or a backtrace ?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/241.