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.


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 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@entry=6) at 
54      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff7825428 in __GI_raise (sig=sig@entry=6) at 
#1  0x00007ffff782702a in __GI_abort () at abort.c:89
#2  0x00007ffff3e6884d in __gnu_cxx::__verbose_terminate_handler () at 
#3  0x00007ffff3e666b6 in __cxxabiv1::__terminate (handler=<optimized out>) at 
#4  0x00007ffff3e66701 in std::terminate () at 
#5  0x00007ffff3e66919 in __cxxabiv1::__cxa_throw 
(obj=obj@entry=0x7fffd00010d0, tinfo=0x7ffff414ec00 <typeinfo for 
std::system_error>, dest=0x7ffff3e91640 <std::system_error::~system_error()>)
    at ../../../../src/libstdc++-v3/libsupc++/eh_throw.cc:87
#6  0x00007ffff3e8f7fe in std::__throw_system_error (__i=1) at 
#7  0x00007ffff4162451 in std::mutex::lock (this=0x25c7280) at 
#8  std::unique_lock<std::mutex>::lock (this=0x7fffe2ffc300) at 
#9  std::unique_lock<std::mutex>::unique_lock (__m=..., this=0x7fffe2ffc300) at 
#10 ros::Participant::read_msg[abi:cxx11]() (this=0x25c7200) at 
#11 0x00007ffff4be9195 in _wrap_Participant_read_msg () from 
#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 
#27 0x00007ffff78f741d in clone () at 

root@ros:/home/ros/zjw/ros/install/ros_x86_64/lib# grep -nrIT -e "_msg_lock" 
/home/ros/zjw/ros/src/ros_comm/roscpp/include/discovery/participant.h: 144     
:  std::mutex _msg_lock;
53:    std::lock_guard<std::mutex> lg(_msg_lock);
62:  std::unique_lock<std::mutex> ul(_msg_lock);

Xenomai mailing list

Reply via email to