[Xenomai] Odp: Re: [roscore issue for "Operation not permitted"] pthread_mutex_lock failed: operation not permitted

Mariusz Janiak mariuszjaniak at wp.pl
Thu Jul 12 12:51:53 CEST 2018


Dnia 12 lipca 2018 10:55 gengdongjiu <gengdongjiu at huawei.com> 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 <gengdongjiu at huawei.com> 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<std::mutex 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 at ros:/home/ros/zjw/ros/ins 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/libthre   [New Thread 0x7ffff3586700 (LWP 29315)]   [New Thread 0x7ffff279b700 (LWP 29316)]   [New Thread 0x7ffff1f9a700 (LWP 29317)]   [New Thread 0x7ffff1799700 (LWP 29318)]   [New Thread 0x7ffff0f98700 (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)]   0x00007ffff7825428 in __GI_raise (sig=sig at entry=6) at  ../sysdeps/unix/sysv/linux/rai   54      ../sysdeps/unix/sysv No such file or directory.   (gdb) bt   #0  0x00007ffff7825428 in __GI_raise (sig=sig at entry=6) at  ../sysdeps/unix/sysv/linux/rai   #1  0x00007ffff782702a in __GI_abort () at abort.c:89   #2  0x00007ffff3e6884d in __gnu_cxx::__verbose_terminate () at  ../../../../src/libstdc++-v3/l   #3  0x00007ffff3e666b6 in __cxxabiv1::__terminate (handler=<optimized out>)  at ../../../../src/libstdc++-v3/l   #4  0x00007ffff3e66701 in std::terminate () at  ../../../../src/libstdc++-v3/l   #5  0x00007ffff3e66919 in __cxxabiv1::__cxa_throw  (obj=obj at entry=0x7fffd00010d0, tinfo=0x7ffff414ec00 <typeinfo for  std::system_error>, dest=0x7ffff3e91640  <std::system_error::~system_er      at ../../../../src/libstdc++-v3/l   #6  0x00007ffff3e8f7fe in std::__throw_system_error (__i=1) at  ../../../../../src/libstdc++-v   #7  0x00007ffff4162451 in std::mutex::lock (this=0x25c7280) at  /usr/include/c++/5/mutex:139   #8  std::unique_lock<std::mutex> (this=0x7fffe2ffc300) at  /usr/include/c++/5/mutex:485   #9  std::unique_lock<std::mutex> (__m=..., this=0x7fffe2ffc300)  at /usr/include/c++/5/mutex:415   #10 ros::Participant::read_msg[abi (this=0x25c7200) at  /home/ros/zjw/ros/src/ros_comm   #11 0x00007ffff4be9195 in _wrap_Participant_read_msg () from  /home/ros/zjw/ros/install/ros_   #12 0x00000000004bc3fa in PyEval_EvalFrameEx ()   #13 0x00000000004c136f in PyEval_EvalFrameEx ()   #14 0x00000000004b9ab6 in PyEval_EvalCodeEx ()   #15 0x00000000004d55f3 in ?? ()   #16 0x00000000004a577e in PyObject_Call ()   #17 0x00000000004bed3d in PyEval_EvalFrameEx ()   #18 0x00000000004c136f in PyEval_EvalFrameEx ()   #19 0x00000000004c136f in PyEval_EvalFrameEx ()   #20 0x00000000004b9ab6 in PyEval_EvalCodeEx ()   #21 0x00000000004d54b9 in ?? ()   #22 0x00000000004eebee in ?? ()   #23 0x00000000004a577e in PyObject_Call ()   #24 0x00000000004c5e10 in PyEval_CallObjectWithKeywords ()   #25 0x0000000000589172 in ?? ()   #26 0x00007ffff7bc16ba in start_thread (arg=0x7fffe2ffd700) at  pthread_create.c:333   #27 0x00007ffff78f741d in clone () at  ../sysdeps/unix/sysv/linux/x86   (gdb)     root at ros:/home/ros/zjw/ros/ins grep -nrIT -e "_msg_lock"  /home/ros/zjw/ros/src/ros_comm   /home/ros/zjw/ros/src/ros_comm 144  :  std::mutex _msg_lock;   /home/ros/zjw/ros/src/ros_comm  53:    std::lock_guard<std::mut lg(_msg_lock);   /home/ros/zjw/ros/src/ros_comm  62:  std::unique_lock<std::mutex> ul(_msg_lock);     .     ______________________________  Xenomai mailing list   Xenomai at xenomai.org  xenomai.org xenomai.org


More information about the Xenomai mailing list