GNOME Bugzilla – Bug 768630
CGLCreateContext hangs on a lock with context sharing and java (maybe CFRunLoop issues?)
Last modified: 2018-11-03 11:47:44 UTC
I have a playbin-pipeline of a local file, which is initially being set to paused to allow for seeking etc. When I call gst_element_get_state() afterwards, to wait for the asynchronous state change to succeed this hangs forever. My application uses GL context sharing. Marcin spotted the following line in the logs, which he thought was suspicious "pad_query:<glcolorconvertelement0:src> pad peer query failed". Indeed, when I remove the glcolorconvert from the pipeline, the problem (hang) disappears. You find the setup of the application's pipeline here: https://github.com/gohai/processing-glvideo/blob/b8bc94f59630b010e52fe25846e1c5423c8398dd/src/native/impl.c#L240 I am attaching a GST_DEBUG=*:5 trace. When I gdb the process as it hangs I find the following two threads that are gstreamer-related:
+ Trace 236457
Created attachment 331155 [details] Trace with GDB_DEBUG=*:5 (gzipped for size)
So, CGLCreateContext () is the most likely cause of this which would require that you are pumping the CFRunLoop to be able to continue. 1. It seems from the log you're using the binaries from the GStreamer project correct? 2. I also need a backtrace of all the threads to see what's happening on the main thread.
1. Yes, I am using the binaries provided. 2. Attaching output of "thread apply all backtrace" below. Is there anything I can do to pump CFRunLoop myself? (e.g. by timing out the wait every couple of ms to do so)
Created attachment 331162 [details] Backtrace of all threads
That backtrace isn't all that useful. Can you get one using lldb instead? For CFRunLoop, look at the documentation: https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFRunLoopRef/ You'll probably also have to figure out what Java is doing with the CFRunloop in order to integrate them properly.
I am attaching a backtrace with lldb below.
Created attachment 331211 [details] Backtrace of all threads w/ lldb
I haven't found code that would let me believe that CFRunLoop is somehow used within the JOGL NEWT windowing toolkit, or within OpenJDK. Calling CFRunLoopGetCurrent() and CFRunLoopGetMain() before I wait for the state change hands me two different, non-NULL pointers back. I also tried calling CFRunLoopRunInMode() myself, but so far this hasn't made a difference. (see https://github.com/gohai/processing-glvideo/commit/d31ca59732b463d4745b8dacce065bae9dce0a35)
(In reply to gohai from comment #8) > I haven't found code that would let me believe that CFRunLoop is somehow > used within the JOGL NEWT windowing toolkit, or within OpenJDK. It does because it's in your backtrace. Look at thread 1 in the lldb backtrace. > Calling CFRunLoopGetCurrent() and CFRunLoopGetMain() before I wait for the > state change hands me two different, non-NULL pointers back. That could be problematic. > I also tried calling CFRunLoopRunInMode() myself, but so far this hasn't > made a difference. I doubt this would achieve anything. You probably need to make the main CFRunLoop iterate somehow. http://stackoverflow.com/questions/8750690/osx-javavm-awt-swing-and-possibly-a-deadlock sounds very similar to what may happen in your case.
You're right about the other CFRunLoop. It seems to be created by the Java launcher, specifically CreateExecutionEnvironment inside java_md.c. Unfortunately I haven't been able to find a the source for the very implementation (Darwin on Oracle's JRE). I tried to wake up the main run loop instead, to no avail: https://github.com/gohai/processing-glvideo/commit/eb6cd587e9254dee6735a24601c5c324d0b0f496
Anything else that I can provide to move this bug off NEEDINFO?
Can you try to create an Obj-C testcase that reproduces exactly the situation that happens with Java? That would make it easier for someone to look into this and think of possible solutions.
Hi Sebastian. Unfortunately I haven't done any Obj-C or OS X development so far, so it's unlikely I'll be able to put together a test-case for that, sorry.
Hi guys, it turns our that if you run the seek operation AFTER the second stream has an available frame, then there is no hang. Matt (sitting with me at the same table) suggested that I generate the GST_DEBUG outputs for the after and before situations, which I did. I'm attaching those two files.
Created attachment 337223 [details] GST_DEBUG for seek before second stream has a frame ready This one hangs
Created attachment 337224 [details] GST_DEBUG for seek after second stream has a frame ready This one does not hang
Created attachment 337228 [details] GST_DEBUG using seek before second stream has frame ready
Created attachment 337229 [details] GST_DEBUG using seek after second stream has frame ready
Tested GLVideo using a global gst_display object (https://github.com/gohai/processing-glvideo/commit/2ad5b1fe2c7aba112e254e6f343c8a983038c3ce), and a build of GStreamer 1.9.90 with GSTREAMER_GLIB_COCOA_NSAPPLICATION disabled in the recipe for gst-plugins-bad, but the two video tesst case still hangs after performing a seek operation before the stream being ready.
-- 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/gst-plugins-base/issues/275.