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.<div><br></div><div>Josh<br><br><div class="gmail_quote">

On Tue, Nov 9, 2010 at 6:47 PM, Mrinal Kalakrishnan <span dir="ltr"><<a href="mailto:mail@mrinal.net">mail@mrinal.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

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