GNOME Bugzilla – Bug 787208
ipcpipeline: doesn't work on macOS
Last modified: 2018-02-17 10:59:58 UTC
Trying the ipcpipeline1 example, the state-change on the master pipeline never completes. Looks like gst_ipc_pipeline_comm_reply_request() is never called so the req cond isn't signaled. (lldb) bt all * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x00007fff91209bf2 libsystem_kernel.dylib`__psynch_cvwait + 10 frame #1: 0x00007fff912f5833 libsystem_pthread.dylib`_pthread_cond_wait + 769 frame #2: 0x00000001003ad8c6 libglib-2.0.0.dylib`g_cond_wait_until + 129 frame #3: 0x00000001018a7657 libgstipcpipeline.so`comm_request_wait(comm=0x000000010104d108, req=0x00000001007a4a10, ack_type=ACK_TYPE_TIMED) at gstipcpipelinecomm.c:106 frame #4: 0x00000001018a3fdf libgstipcpipeline.so`gst_ipc_pipeline_comm_sync_fd(comm=0x000000010104d108, id=1, query=0x0000000000000000, ret=0x00007fff5fbfc904, ack_type=ACK_TYPE_TIMED, type=COMM_REQUEST_TYPE_STATE_CHANGE) at gstipcpipelinecomm.c:210 frame #5: 0x00000001018a5241 libgstipcpipeline.so`gst_ipc_pipeline_comm_write_state_change_to_fd(comm=0x000000010104d108, transition=GST_STATE_CHANGE_NULL_TO_READY) at gstipcpipelinecomm.c:1208 frame #6: 0x00000001018ac9dd libgstipcpipeline.so`gst_ipc_pipeline_sink_change_state(element=0x000000010104d000, transition=GST_STATE_CHANGE_NULL_TO_READY) at gstipcpipelinesink.c:654 frame #7: 0x0000000100179d03 libgstreamer-1.0.0.dylib`gst_element_change_state(element=0x000000010104d000, transition=GST_STATE_CHANGE_NULL_TO_READY) at gstelement.c:2815 frame #8: 0x000000010017c8de libgstreamer-1.0.0.dylib`gst_element_set_state_func(element=0x000000010104d000, state=GST_STATE_READY) at gstelement.c:2769 frame #9: 0x00000001001792f2 libgstreamer-1.0.0.dylib`gst_element_set_state(element=0x000000010104d000, state=GST_STATE_READY) at gstelement.c:2670 frame #10: 0x00000001001429cd libgstreamer-1.0.0.dylib`gst_bin_element_set_state(bin=0x0000000101046140, element=0x000000010104d000, base_time=0, start_time=0, current=GST_STATE_NULL, next=GST_STATE_READY) at gstbin.c:2596 frame #11: 0x000000010013c2a2 libgstreamer-1.0.0.dylib`gst_bin_change_state_func(element=0x0000000101046140, transition=GST_STATE_CHANGE_NULL_TO_READY) at gstbin.c:2938 frame #12: 0x00000001001b9776 libgstreamer-1.0.0.dylib`gst_pipeline_change_state(element=0x0000000101046140, transition=GST_STATE_CHANGE_NULL_TO_READY) at gstpipeline.c:508 frame #13: 0x0000000100179d03 libgstreamer-1.0.0.dylib`gst_element_change_state(element=0x0000000101046140, transition=GST_STATE_CHANGE_NULL_TO_READY) at gstelement.c:2815 frame #14: 0x000000010017c8de libgstreamer-1.0.0.dylib`gst_element_set_state_func(element=0x0000000101046140, state=GST_STATE_PLAYING) at gstelement.c:2769 frame #15: 0x00000001001792f2 libgstreamer-1.0.0.dylib`gst_element_set_state(element=0x0000000101046140, state=GST_STATE_PLAYING) at gstelement.c:2670 frame #16: 0x00000001000037a9 ipcpipeline1`start_source(fdin=3, fdout=3) at ipcpipeline1.c:123 frame #17: 0x0000000100003552 ipcpipeline1`main(argc=1, argv=0x00007fff5fbfd6f0) at ipcpipeline1.c:185 frame #18: 0x00007fff910db235 libdyld.dylib`start + 1 thread #2, name = 'reader' frame #0: 0x00007fff91209eb6 libsystem_kernel.dylib`__select + 10 frame #1: 0x00000001018a7af3 libgstipcpipeline.so`update_adapter(comm=0x000000010104d108) at gstipcpipelinecomm.c:1727 frame #2: 0x00000001018a66a0 libgstipcpipeline.so`reader_thread(data=0x000000010104d108) at gstipcpipelinecomm.c:2157 frame #3: 0x0000000100393b16 libglib-2.0.0.dylib`g_thread_proxy + 90 frame #4: 0x00007fff912f493b libsystem_pthread.dylib`_pthread_body + 180 frame #5: 0x00007fff912f4887 libsystem_pthread.dylib`_pthread_start + 286 frame #6: 0x00007fff912f408d libsystem_pthread.dylib`thread_start + 13
Hmm, I guess then that select() doesn't wake up in update_adapter()... Maybe there is some platform-specific quirk there that I'm not aware about? I wonder if GstPoll would work instead...
Check this out. commit 15927b6511bc8304ae144a45c9fbfca88e5dd641 Author: George Kiagiadakis <george.kiagiadakis@collabora.com> Date: Mon Sep 4 15:52:03 2017 +0300 ipcpipeline: use GstPoll instead of select() to watch for socket activity ... and make that code more readable in the process https://bugzilla.gnome.org/show_bug.cgi?id=787208
Same behavior :( The bt still shows comm_request_wait() waits forever on the GCond.
Could you please run it with GST_DEBUG=ipcpipeline*:TRACE and post here the gstsrc.log and gstsink.log that are generated in the working directory?
Created attachment 359183 [details] gstsrc.log gstsink.log is empty.
It looks as if the slave process does not even start. There should be some output from ipcpipelinesrc in gstsink.log, even if it can't communicate with the master.
It works now \o/