Re: [Xenomai] Odp: Re: [roscore issue for "Operation not permitted"] pthread_mutex_lock failed: operation not permitted
Agree your opinion that roscore is only used to setup the connection. ok, we will try to deploy it to secondary domain and check the test results 发件人:Mariusz Janiak 收件人:Greg Gallagher,gengdongjiu, 抄 送:xenomai@xenomai.org,zhangjianwei (D), 时间:2018-07-12 19:51:16 主 题:RE: Odp: Re: [Xenomai] [roscore issue for "Operation not permitted"] pthread_mutex_lock failed: operation not permitted Hi, In my opinion, if we are already considering such an option, roscore in primary is not needed. Probably you use nodelets so, in this case you communicate within one process, between threads. The communication with external world wan't be real-time so roscore can be run in secondary. It is needed only during establishing connections, after that the communication is direct between nodes. Best, Mariusz Dnia 12 lipca 2018 13:41 gengdongjiu napisał(a): cc jianwei 发件人:gengdongjiu 收件人:Mariusz Janiak,Greg Gallagher, 抄 送:xenomai@xenomai.org, 时间:2018-07-12 19:39:17 主 题:RE: Odp: Re: [Xenomai] [roscore issue for "Operation not permitted"] pthread_mutex_lock failed: operation not permitted thanks for the suggestion. we have modified the ROS1 to make it realtime according to ROS2, but for some reasons, we keep the roscore master node, so can you give some advice how to deploy the roscore ? should we deployed the roscore to primary domain or secondary domain? Now deploying it to primary domain has this bug, thanks. 发件人:Mariusz Janiak 收件人:Greg Gallagher,gengdongjiu, 抄 送:xenomai@xenomai.org, 时间:2018-07-12 18:52:06 主 题:Odp: Re: [Xenomai] [roscore issue for "Operation not permitted"] pthread_mutex_lock failed: operation not permitted Dnia 12 lipca 2018 10:55 gengdongjiu napisał(a): Hi Greg, Thanks for the answer, On 2018/7/11 22:09, Greg Gallagher wrote: Have you looked at any of the ROS frameworks that use Xenomai? Is the expectation that roscore runs in the secondary domain and your ros based application runs in the primary domain? Yes, we have looked at the the ROS frameworks that use Xenomai. do you have any suggestion? Please consider OROCOS for RT part instead of ROS. Eventually ROS2. we are not very familiar with the ROS. In our test, we used the ROS pub and sub to do communication. From our test, if roscore runs in the secondary (normal linux)domain, it will not have such issue. should the roscore run in the secondary domain or the primary domain? I do not know which domain it should run into. thanks a lot. ROS haven't been designed as a real-time framework, especially in communication domain (ros topics + TCP + XML RPC). Best, Mariusz -Greg On Wed, Jul 11, 2018 at 10:03 AM, gengdongjiu wrote: Hi, Philippe/ Gilles/ Jan/ Alexis/others, I’m running ros on Xenomai, with Xenomai-3.07 and linux kernel 4.4.71. I first export CFLAGS and LDFLAGS of posix skin. And compile ros project with posix skin successfully. Then, I run roscore as root user, it throws a std::system_error. So I debug roscore with gdb. According to the gdb backtrace frame #10, it’s the 62 lines of participant.cpp that caused the problem. Which is “std::unique_lock ul(_msg_lock);”. As far as I know, initializing a unique_lock will call _msg_lock.lock(),and _msg_lock is a std::mutex, _msg_lock.lock() will call pthread_mutex_lock(). According the to the error message “Operation not permitted”. Pthread_mutex_lock() must return EPERM, and pthread_mutex_lock return EPRM only if the mutex is not process-shared and does not belong to the current process or the caller context is invalid. So my question is why compiling and running ros on xenomai will cause pthread_mutex_lock() return EPERM? Does current calling context is invalid ? And how can I solve this problem, does anybody have any insight? By the way, it’s perfect fine to compiling and running ros on linux with the same code. Thanks. - root@ros:/home/ros/zjw/ros/install/ros_x86_64/lib# roscore terminate called after throwing an instance of 'std::system_error' what(): Operation not permitted Aborted (core dumped) (gdb) r `which roscore` Starting program: /usr/bin/python `which roscore` [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x73586700 (LWP 29315)] [New Thread 0x7279b700 (LWP 29316)] [New Thread 0x71f9a700 (LWP 29317)] [New Thread 0x71799700 (LWP 29318)] [New Thread 0x70f98700 (LWP 29319)] [New Thread 0x7fffe3fff700 (LWP 29320)] [New Thread 0x7fffe37fe700 (LWP 29321)] [New Thread 0x7fffe2ffd700 (LWP 29322)] terminate called after throwing an instance of 'std::system_error' what(): Operation not permitted Thread 9 "python" received signal SIGABRT, Aborted. [Switching to Thread 0x7fffe2ffd700 (LWP 29322)] 0x77825428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
Re: [Xenomai] Odp: Re: [roscore issue for "Operation not permitted"] pthread_mutex_lock failed: operation not permitted
Hi, In my opinion, if we are already considering such an option, roscore in primary is not needed. Probably you use nodelets so, in this case you communicate within one process, between threads. The communication with external world wan't be real-time so roscore can be run in secondary. It is needed only during establishing connections, after that the communication is direct between nodes.Best, Mariusz Dnia 12 lipca 2018 13:41 gengdongjiunapisał(a): cc jianwei 发件人: gengdongjiu 收件人: Mariusz Janiak,Greg Gallagher, 抄 送: xenomai@xenomai.org, 时间: 2018-07-12 19:39:17 主 题: RE: Odp: Re: [Xenomai] [roscore issue for "Operation not permitted"] pthread_mutex_lock failed: operation not permitted thanks for the suggestion. we have modified the ROS1 to make it realtime according to ROS2, but for some reasons, we keep the roscore master node, so can you give some advice how to deploy the roscore ? should we deployed the roscore to primary domain or secondary domain? Now deploying it to primary domain has this bug, thanks. 发件人: Mariusz Janiak 收件人: Greg Gallagher,gengdongjiu, 抄 送: xenomai@xenomai.org, 时间: 2018-07-12 18:52:06 主 题: Odp: Re: [Xenomai] [roscore issue for "Operation not permitted"] pthread_mutex_lock failed: operation not permitted Dnia 12 lipca 2018 10:55 gengdongjiu napisał(a): Hi Greg, Thanks for the answer, On 2018/7/11 22:09, Greg Gallagher wrote: Have you looked at any of the ROS frameworks that use Xenomai? Is the expectation that roscore runs in the secondary domain and your ros based application runs in the primary domain? Yes, we have looked at the the ROS frameworks that use Xenomai. do you have any suggestion? Please consider OROCOS for RT part instead of ROS. Eventually ROS2. we are not very familiar with the ROS. In our test, we used the ROS pub and sub to do communication. From our test, if roscore runs in the secondary (normal linux)domain, it will not have such issue. should the roscore run in the secondary domain or the primary domain? I do not know which domain it should run into. thanks a lot. ROS haven't been designed as a real-time framework, especially in communication domain (ros topics + TCP + XML RPC). Best, Mariusz -Greg On Wed, Jul 11, 2018 at 10:03 AM, gengdongjiu wrote: Hi, Philippe/ Gilles/ Jan/ Alexis/others, I’m running ros on Xenomai, with Xenomai-3.07 and linux kernel 4.4.71. I first export CFLAGS and LDFLAGS of posix skin. And compile ros project with posix skin successfully. Then, I run roscore as root user, it throws a std::system_error. So I debug roscore with gdb. According to the gdb backtrace frame #10, it’s the 62 lines of participant.cpp that caused the problem. Which is “std::unique_lock
Re: [Xenomai] Odp: Re: [roscore issue for "Operation not permitted"] pthread_mutex_lock failed: operation not permitted
cc jianwei 发件人:gengdongjiu 收件人:Mariusz Janiak,Greg Gallagher, 抄 送:xenomai@xenomai.org, 时间:2018-07-12 19:39:17 主 题:RE: Odp: Re: [Xenomai] [roscore issue for "Operation not permitted"] pthread_mutex_lock failed: operation not permitted thanks for the suggestion. we have modified the ROS1 to make it realtime according to ROS2, but for some reasons, we keep the roscore master node, so can you give some advice how to deploy the roscore ? should we deployed the roscore to primary domain or secondary domain? Now deploying it to primary domain has this bug, thanks. 发件人:Mariusz Janiak 收件人:Greg Gallagher,gengdongjiu, 抄 送:xenomai@xenomai.org, 时间:2018-07-12 18:52:06 主 题:Odp: Re: [Xenomai] [roscore issue for "Operation not permitted"] pthread_mutex_lock failed: operation not permitted Dnia 12 lipca 2018 10:55 gengdongjiu napisał(a): Hi Greg, Thanks for the answer, On 2018/7/11 22:09, Greg Gallagher wrote: Have you looked at any of the ROS frameworks that use Xenomai? Is the expectation that roscore runs in the secondary domain and your ros based application runs in the primary domain? Yes, we have looked at the the ROS frameworks that use Xenomai. do you have any suggestion? Please consider OROCOS for RT part instead of ROS. Eventually ROS2. we are not very familiar with the ROS. In our test, we used the ROS pub and sub to do communication. From our test, if roscore runs in the secondary (normal linux)domain, it will not have such issue. should the roscore run in the secondary domain or the primary domain? I do not know which domain it should run into. thanks a lot. ROS haven't been designed as a real-time framework, especially in communication domain (ros topics + TCP + XML RPC). Best, Mariusz -Greg On Wed, Jul 11, 2018 at 10:03 AM, gengdongjiu wrote: Hi, Philippe/ Gilles/ Jan/ Alexis/others, I’m running ros on Xenomai, with Xenomai-3.07 and linux kernel 4.4.71. I first export CFLAGS and LDFLAGS of posix skin. And compile ros project with posix skin successfully. Then, I run roscore as root user, it throws a std::system_error. So I debug roscore with gdb. According to the gdb backtrace frame #10, it’s the 62 lines of participant.cpp that caused the problem. Which is “std::unique_lock ul(_msg_lock);”. As far as I know, initializing a unique_lock will call _msg_lock.lock(),and _msg_lock is a std::mutex, _msg_lock.lock() will call pthread_mutex_lock(). According the to the error message “Operation not permitted”. Pthread_mutex_lock() must return EPERM, and pthread_mutex_lock return EPRM only if the mutex is not process-shared and does not belong to the current process or the caller context is invalid. So my question is why compiling and running ros on xenomai will cause pthread_mutex_lock() return EPERM? Does current calling context is invalid ? And how can I solve this problem, does anybody have any insight? By the way, it’s perfect fine to compiling and running ros on linux with the same code. Thanks. - root@ros:/home/ros/zjw/ros/install/ros_x86_64/lib# roscore terminate called after throwing an instance of 'std::system_error' what(): Operation not permitted Aborted (core dumped) (gdb) r `which roscore` Starting program: /usr/bin/python `which roscore` [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x73586700 (LWP 29315)] [New Thread 0x7279b700 (LWP 29316)] [New Thread 0x71f9a700 (LWP 29317)] [New Thread 0x71799700 (LWP 29318)] [New Thread 0x70f98700 (LWP 29319)] [New Thread 0x7fffe3fff700 (LWP 29320)] [New Thread 0x7fffe37fe700 (LWP 29321)] [New Thread 0x7fffe2ffd700 (LWP 29322)] terminate called after throwing an instance of 'std::system_error' what(): Operation not permitted Thread 9 "python" received signal SIGABRT, Aborted. [Switching to Thread 0x7fffe2ffd700 (LWP 29322)] 0x77825428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x77825428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 #1 0x7782702a in __GI_abort () at abort.c:89 #2 0x73e6884d in __gnu_cxx::__verbose_terminate_handler () at ../../../../src/libstdc++-v3/libsupc++/vterminate.cc:95 #3 0x73e666b6 in __cxxabiv1::__terminate (handler=) at ../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:47 #4 0x73e66701 in std::terminate () at ../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:57 #5 0x73e66919 in __cxxabiv1::__cxa_throw (obj=obj@entry=0x7fffd00010d0, tinfo=0x7414ec00 , dest=0x73e91640 ) at ../../../../src/libstdc++-v3/libsupc++/eh_throw.cc:87 #6 0x73e8f7fe in std::__throw_system_error (__i=1) at ../../../../../src/libstdc++-v3/src/c++11/functexcept.cc:127 #7 0x74162451 i
Re: [Xenomai] Odp: Re: [roscore issue for "Operation not permitted"] pthread_mutex_lock failed: operation not permitted
thanks for the suggestion. we have modified the ROS1 to make it realtime according to ROS2, but for some reasons, we keep the roscore master node, so can you give some advice how to deploy the roscore ? should we deployed the roscore to primary domain or secondary domain? Now deploying it to primary domain has this bug, thanks. 发件人:Mariusz Janiak 收件人:Greg Gallagher,gengdongjiu, 抄 送:xenomai@xenomai.org, 时间:2018-07-12 18:52:06 主 题:Odp: Re: [Xenomai] [roscore issue for "Operation not permitted"] pthread_mutex_lock failed: operation not permitted Dnia 12 lipca 2018 10:55 gengdongjiu napisał(a): Hi Greg, Thanks for the answer, On 2018/7/11 22:09, Greg Gallagher wrote: Have you looked at any of the ROS frameworks that use Xenomai? Is the expectation that roscore runs in the secondary domain and your ros based application runs in the primary domain? Yes, we have looked at the the ROS frameworks that use Xenomai. do you have any suggestion? Please consider OROCOS for RT part instead of ROS. Eventually ROS2. we are not very familiar with the ROS. In our test, we used the ROS pub and sub to do communication. From our test, if roscore runs in the secondary (normal linux)domain, it will not have such issue. should the roscore run in the secondary domain or the primary domain? I do not know which domain it should run into. thanks a lot. ROS haven't been designed as a real-time framework, especially in communication domain (ros topics + TCP + XML RPC). Best, Mariusz -Greg On Wed, Jul 11, 2018 at 10:03 AM, gengdongjiu wrote: Hi, Philippe/ Gilles/ Jan/ Alexis/others, I’m running ros on Xenomai, with Xenomai-3.07 and linux kernel 4.4.71. I first export CFLAGS and LDFLAGS of posix skin. And compile ros project with posix skin successfully. Then, I run roscore as root user, it throws a std::system_error. So I debug roscore with gdb. According to the gdb backtrace frame #10, it’s the 62 lines of participant.cpp that caused the problem. Which is “std::unique_lock ul(_msg_lock);”. As far as I know, initializing a unique_lock will call _msg_lock.lock(),and _msg_lock is a std::mutex, _msg_lock.lock() will call pthread_mutex_lock(). According the to the error message “Operation not permitted”. Pthread_mutex_lock() must return EPERM, and pthread_mutex_lock return EPRM only if the mutex is not process-shared and does not belong to the current process or the caller context is invalid. So my question is why compiling and running ros on xenomai will cause pthread_mutex_lock() return EPERM? Does current calling context is invalid ? And how can I solve this problem, does anybody have any insight? By the way, it’s perfect fine to compiling and running ros on linux with the same code. Thanks. - root@ros:/home/ros/zjw/ros/install/ros_x86_64/lib# roscore terminate called after throwing an instance of 'std::system_error' what(): Operation not permitted Aborted (core dumped) (gdb) r `which roscore` Starting program: /usr/bin/python `which roscore` [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x73586700 (LWP 29315)] [New Thread 0x7279b700 (LWP 29316)] [New Thread 0x71f9a700 (LWP 29317)] [New Thread 0x71799700 (LWP 29318)] [New Thread 0x70f98700 (LWP 29319)] [New Thread 0x7fffe3fff700 (LWP 29320)] [New Thread 0x7fffe37fe700 (LWP 29321)] [New Thread 0x7fffe2ffd700 (LWP 29322)] terminate called after throwing an instance of 'std::system_error' what(): Operation not permitted Thread 9 "python" received signal SIGABRT, Aborted. [Switching to Thread 0x7fffe2ffd700 (LWP 29322)] 0x77825428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x77825428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 #1 0x7782702a in __GI_abort () at abort.c:89 #2 0x73e6884d in __gnu_cxx::__verbose_terminate_handler () at ../../../../src/libstdc++-v3/libsupc++/vterminate.cc:95 #3 0x73e666b6 in __cxxabiv1::__terminate (handler=) at ../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:47 #4 0x73e66701 in std::terminate () at ../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:57 #5 0x73e66919 in __cxxabiv1::__cxa_throw (obj=obj@entry=0x7fffd00010d0, tinfo=0x7414ec00 , dest=0x73e91640 ) at ../../../../src/libstdc++-v3/libsupc++/eh_throw.cc:87 #6 0x73e8f7fe in std::__throw_system_error (__i=1) at ../../../../../src/libstdc++-v3/src/c++11/functexcept.cc:127 #7 0x74162451 in std::mutex::lock (this=0x25c7280) at /usr/include/c++/5/mutex:139 #8 std::unique_lock::lock (this=0x7fffe2ffc300) at /usr/include/c++/5/mutex:485 #9 std::unique_lock::unique_lock (__m=..., this=0x7fffe2ffc300) at /usr/include/c++/