[ros-users] rosconsole initialization problem when linked with xenomai

[Mrinal Kalakrishnan]

For the record, our problem may have been related to the posix skin
(posix wrapper functions) of xenomai. After tracing through a lot of
code, we found that the call to pthread_mutex_init() for the
initialization of g_init_mutex resulted in junk values being written
to the mutex:

before pthread_mutex_init:  {__data = {__lock = 0, __count = 0,
__owner = 0, __nusers = 0 ...

after pthread_mutex_init: {__data = {__lock = -2038037757, __count =
0, __owner = 131724800, __nusers = 4294953216 ...

Compiling it without the posix wrappers fixes it, but I hope this
doesn't resurface in some other form.

Thanks,
Mrinal

On Tue, Nov 9, 2010 at 7:15 PM, Mrinal Kalakrishnan <mail at mrinal.net> wrote:
> Hey Josh,
>
> Thanks for the clarification, looks like I need to dig into this a little more.
>
> - Mrinal
>
> On Tue, Nov 9, 2010 at 7:07 PM, Josh Faust <jfaust at willowgarage.com> wrote:
>> This is only a problem across different compilation units.  Within the same
>> compilation unit construction order is defined as the order they're defined
>> in that unit.
>> Josh
>>
>> On Tue, Nov 9, 2010 at 6:47 PM, Mrinal Kalakrishnan <mail at mrinal.net> wrote:
>>>
>>> I think that my problem could indeed be a rosconsole bug.
>>>
>>> There are two global variables in rosconsole.cpp (among others):
>>>
>>>    boost::mutex g_init_mutex;
>>>
>>> and
>>>
>>>    StaticInit g_static_init;
>>>
>>> Unfortunately the constructor of g_static_init depends on g_init_mutex
>>> being initialized, because it attempts to lock the mutex. But I
>>> believe the order of construction of global variables can never be
>>> guaranteed, so the mutex could get locked before it is initialized.
>>>
>>> I'm not able to think of a thread-safe way to get around this yet.
>>> I'll ticket this if someone can confirm that it's a bug.
>>>
>>> - Mrinal
>>>
>>> On Tue, Nov 9, 2010 at 3:43 PM, Mrinal Kalakrishnan <mail at mrinal.net>
>>> wrote:
>>> > Hello,
>>> >
>>> > I have a strange problem when linking a ROS application with Xenomai.
>>> > It appears that the constructor for some global objects of rosconsole
>>> > is waiting on a mutex (g_init_mutex). Here is the gdb backtrace when I
>>> > kill the hanging program:
>>> >
>>> > #0  __lll_lock_wait ()
>>> >    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
>>> > #1  0x00007ffff49de295 in _L_lock_949 () from /lib/libpthread.so.0
>>> > #2  0x00007ffff49de0b8 in __pthread_mutex_lock (mutex=0x7ffff6304580)
>>> >    at pthread_mutex_lock.c:61
>>> > #3  0x00007ffff60f384a in boost::mutex::lock ()
>>> >    at /usr/include/boost/thread/pthread/mutex.hpp:50
>>> > #4  boost::unique_lock<boost::mutex>::lock ()
>>> >    at /usr/include/boost/thread/locks.hpp:338
>>> > #5  unique_lock () at /usr/include/boost/thread/locks.hpp:224
>>> > #6  ros::console::initialize ()
>>> >    at
>>> > /tmp/buildd/ros-cturtle-ros-1.2.4/debian/ros-cturtle-ros/opt/ros/cturtle/ros/core/rosconsole/src/rosconsole/rosconsole.cpp:426
>>> > #7  0x00007ffff60fc8d6 in __do_global_ctors_aux ()
>>> >   from /opt/ros/cturtle/ros/core/rosconsole/lib/librosconsole.so
>>> > #8  0x00007ffff60ef803 in _init ()
>>> >   from /opt/ros/cturtle/ros/core/rosconsole/lib/librosconsole.so
>>> > #9  0x00007fffffffe2d8 in ?? ()
>>> > #10 0x00007ffff7ded6e9 in call_init (l=0x7ffff7fda510, argc=-164616432,
>>> >    argv=0x7fffffffe2c8, env=0x7fffffffe2d8) at dl-init.c:70
>>> > #11 0x00007ffff7ded86f in _dl_init (main_map=0x7ffff7ffb000, argc=1,
>>> >    argv=0x7fffffffe2c8, env=0x7fffffffe2d8) at dl-init.c:134
>>> > #12 0x00007ffff7ddfb2a in _dl_start_user () from
>>> > /lib64/ld-linux-x86-64.so.2
>>> > #13 0x0000000000000001 in ?? ()
>>> > #14 0x00007fffffffe524 in ?? ()
>>> > #15 0x0000000000000000 in ?? ()
>>> >
>>> > The same program works fine when not linked with xenomai. This is
>>> > probably not a ROS bug, so I'm not creating a ticket, but I was
>>> > wondering if anyone has seen this before, or has any other ideas. This
>>> > problem either occurs or doesn't based on which objects I link into my
>>> > final binary.
>>> >
>>> > - Mrinal
>>> >
>>> _______________________________________________
>>> ros-users mailing list
>>> ros-users at code.ros.org
>>> https://code.ros.org/mailman/listinfo/ros-users
>>
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>>
>