Revising the code in RTT::Logger after the core dump I attached, it
seems to me that RTT::Logger is not thread safe almost in
RTT::Logger::In::In(const std::string& modname)
Moreover, depending on the implementation of the std::string class
(i.e. reference counted) the mutex used can't protect the user against
race conditions in the string members of the RTT::Logger
It's interesting the alternatives suggested here
http://www.sgi.com/tech/stl/string_discussion.html
In the other hand, it could be safer that all the functions in the
RTT::Logger check first for the log level before performing any action
because it can lose RT when it's manipulating std::strings. Besides,
it could be a good idea to provide a RTT::Logger::In( const char *)
function in order to avoid implicit non-RT-safe conversions from const
char* arguments to std::string till the log level has been checked.
#0 0xb7fc3cc2 in __cxxabiv1::__terminate(void (*)()) () from
/usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0
#1 0xb7fc3d02 in std::terminate() () from
/usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0
#2 0xb7fc3cc5 in __cxxabiv1::__terminate(void (*)()) () from
/usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0
[................................. removed
..........................................]
#2568 0xb7fc3cc5 in __cxxabiv1::__terminate(void (*)()) () from
/usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0
#2569 0xb7fc3d02 in std::terminate() () from
/usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0
#2570 0xb7fc3f5b in __cxa_rethrow () from
/usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0
#2571 0x082ee613 in ?? ()
#2572 0x082ef0a2 in ?? ()
#2573 0xb7fc3cc5 in __cxxabiv1::__terminate(void (*)()) () from
/usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0
#2574 0xb7fc3d02 in std::terminate() () from
/usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0
#2575 0xb7fc5b15 in __cxa_pure_virtual () from
/usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0
---Type <return> to continue, or q <return> to quit---
#2576 0xb71d4491 in RTT::Logger::getLogModule() const () from
/usr/lib/liborocos-rtt-xenomai.so.1.8
#2577 0xb71d735e in RTT::Logger::In::In(std::string const&) () from
/usr/lib/liborocos-rtt-xenomai.so.1.8
#2578 0xb714e79f in RTT::ExecutionEngine::step() () from
/usr/lib/liborocos-rtt-xenomai.so.1.8
#2579 0xb725b301 in RTT::OS::RunnableInterface::loop() () from
/usr/lib/liborocos-rtt-xenomai.so.1.8
#2580 0xb723f1a8 in RTT::NonPeriodicActivity::loop() () from
/usr/lib/liborocos-rtt-xenomai.so.1.8
#2581 0xb725f662 in RTT::OS::singleThread_f(void*) () from
/usr/lib/liborocos-rtt-xenomai.so.1.8
#2582 0xb72635e5 in RTT::OS::detail::rtos_xeno_thread_wrapper(void*) ()
from /usr/lib/liborocos-rtt-xenomai.so.1.8
#2583 0xb8058525 in ?? () from /usr/lib/libnative.so.1
#2584 0x08c0d8d8 in ?? ()
#2585 0xb8057c30 in ?? () from /usr/lib/libnative.so.1
#2586 0xb40f43c4 in ?? ()
#2587 0xb55a2ea0 in ?? ()
#2588 0x00000001 in ?? ()
#2589 0x00000005 in ?? ()
#2590 0xb40f43c4 in ?? ()
#2591 0x08c0d63c in ?? ()
#2592 0x08c0d8f4 in ?? ()
#2593 0x00000062 in ?? ()
#2594 0x00000400 in ?? ()
#2595 0xb40f4b90 in ?? ()
#2596 0x0001022b in ?? ()
#2597 0x00000062 in ?? ()
#2598 0xb7263590 in ?? () from /usr/lib/liborocos-rtt-xenomai.so.1.8
#2599 0xb6f36ff4 in ?? () from /lib/libpthread.so.0
#2600 0xb40f4b90 in ?? ()
#2601 0x00000000 in ?? ()
Is RTT::Logger thread safe?
RTT::Logger is not thread safe nor real-time. See
http://www.orocos.org/wiki/rtt/rtt-20/real-time-logging
for an in-progress proposal to correct this.
Stephen
On Mar 29, 2010, at 06:28 , Carles Lopez wrote:
> Revising the code in RTT::Logger after the core dump I attached, it
> seems to me that RTT::Logger is not thread safe almost in
> RTT::Logger::In::In(const std::string& modname)
> Moreover, depending on the implementation of the std::string class
> (i.e. reference counted) the mutex used can't protect the user against
> race conditions in the string members of the RTT::Logger
> It's interesting the alternatives suggested here
> http://www.sgi.com/tech/stl/string_discussion.html
>
> In the other hand, it could be safer that all the functions in the
> RTT::Logger check first for the log level before performing any action
> because it can lose RT when it's manipulating std::strings. Besides,
> it could be a good idea to provide a RTT::Logger::In( const char *)
> function in order to avoid implicit non-RT-safe conversions from const
> char* arguments to std::string till the log level has been checked.
>
>
> #0 0xb7fc3cc2 in __cxxabiv1::__terminate(void (*)()) () from
> /usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0
> #1 0xb7fc3d02 in std::terminate() () from
> /usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0
> #2 0xb7fc3cc5 in __cxxabiv1::__terminate(void (*)()) () from
> /usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0
> [................................. removed
> ..........................................]
> #2568 0xb7fc3cc5 in __cxxabiv1::__terminate(void (*)()) () from
> /usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0
> #2569 0xb7fc3d02 in std::terminate() () from
> /usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0
> #2570 0xb7fc3f5b in __cxa_rethrow () from
> /usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0
> #2571 0x082ee613 in ?? ()
> #2572 0x082ef0a2 in ?? ()
> #2573 0xb7fc3cc5 in __cxxabiv1::__terminate(void (*)()) () from
> /usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0
> #2574 0xb7fc3d02 in std::terminate() () from
> /usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0
> #2575 0xb7fc5b15 in __cxa_pure_virtual () from
> /usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0
> ---Type <return> to continue, or q <return> to quit---
> #2576 0xb71d4491 in RTT::Logger::getLogModule() const () from
> /usr/lib/liborocos-rtt-xenomai.so.1.8
> #2577 0xb71d735e in RTT::Logger::In::In(std::string const&) () from
> /usr/lib/liborocos-rtt-xenomai.so.1.8
> #2578 0xb714e79f in RTT::ExecutionEngine::step() () from
> /usr/lib/liborocos-rtt-xenomai.so.1.8
> #2579 0xb725b301 in RTT::OS::RunnableInterface::loop() () from
> /usr/lib/liborocos-rtt-xenomai.so.1.8
> #2580 0xb723f1a8 in RTT::NonPeriodicActivity::loop() () from
> /usr/lib/liborocos-rtt-xenomai.so.1.8
> #2581 0xb725f662 in RTT::OS::singleThread_f(void*) () from
> /usr/lib/liborocos-rtt-xenomai.so.1.8
> #2582 0xb72635e5 in RTT::OS::detail::rtos_xeno_thread_wrapper(void*) ()
> from /usr/lib/liborocos-rtt-xenomai.so.1.8
> #2583 0xb8058525 in ?? () from /usr/lib/libnative.so.1
> #2584 0x08c0d8d8 in ?? ()
> #2585 0xb8057c30 in ?? () from /usr/lib/libnative.so.1
> #2586 0xb40f43c4 in ?? ()
> #2587 0xb55a2ea0 in ?? ()
> #2588 0x00000001 in ?? ()
> #2589 0x00000005 in ?? ()
> #2590 0xb40f43c4 in ?? ()
> #2591 0x08c0d63c in ?? ()
> #2592 0x08c0d8f4 in ?? ()
> #2593 0x00000062 in ?? ()
> #2594 0x00000400 in ?? ()
> #2595 0xb40f4b90 in ?? ()
> #2596 0x0001022b in ?? ()
> #2597 0x00000062 in ?? ()
> #2598 0xb7263590 in ?? () from /usr/lib/liborocos-rtt-xenomai.so.1.8
> #2599 0xb6f36ff4 in ?? () from /lib/libpthread.so.0
> #2600 0xb40f4b90 in ?? ()
> #2601 0x00000000 in ?? ()
>
>
>
Is RTT::Logger thread safe?
I can accept that the logger is not RT safe (and it's so clear in the
documentation that it isn't) but it's more difficult to admit that
it's not thread safe because.... well... the logger is extensively
used inside RTT in RT threads for example. In particular, I'm worried
about the use of the function RTT::Logger::In( const std::string&
module ) because it's reassigning the internal std::string without
using mayLog() to check for the log level.
Anyway, are you proposing that it's better compile all orocos with no Logger?
On Mon, Mar 29, 2010 at 14:33, S Roderick <kiwi [dot] net [..] ...> wrote:
> RTT::Logger is not thread safe nor real-time. See
>
> http://www.orocos.org/wiki/rtt/rtt-20/real-time-logging
>
> for an in-progress proposal to correct this.
> Stephen
>
> On Mar 29, 2010, at 06:28 , Carles Lopez wrote:
>
>> Revising the code in RTT::Logger after the core dump I attached, it
>> seems to me that RTT::Logger is not thread safe almost in
>> RTT::Logger::In::In(const std::string& modname)
>> Moreover, depending on the implementation of the std::string class
>> (i.e. reference counted) the mutex used can't protect the user against
>> race conditions in the string members of the RTT::Logger
>> It's interesting the alternatives suggested here
>> http://www.sgi.com/tech/stl/string_discussion.html
>>
>> In the other hand, it could be safer that all the functions in the
>> RTT::Logger check first for the log level before performing any action
>> because it can lose RT when it's manipulating std::strings. Besides,
>> it could be a good idea to provide a RTT::Logger::In( const char *)
>> function in order to avoid implicit non-RT-safe conversions from const
>> char* arguments to std::string till the log level has been checked.
>>
>>
>> #0 0xb7fc3cc2 in __cxxabiv1::__terminate(void (*)()) () from
>> /usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0
>> #1 0xb7fc3d02 in std::terminate() () from
>> /usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0
>> #2 0xb7fc3cc5 in __cxxabiv1::__terminate(void (*)()) () from
>> /usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0
>> [................................. removed
>> ..........................................]
>> #2568 0xb7fc3cc5 in __cxxabiv1::__terminate(void (*)()) () from
>> /usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0
>> #2569 0xb7fc3d02 in std::terminate() () from
>> /usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0
>> #2570 0xb7fc3f5b in __cxa_rethrow () from
>> /usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0
>> #2571 0x082ee613 in ?? ()
>> #2572 0x082ef0a2 in ?? ()
>> #2573 0xb7fc3cc5 in __cxxabiv1::__terminate(void (*)()) () from
>> /usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0
>> #2574 0xb7fc3d02 in std::terminate() () from
>> /usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0
>> #2575 0xb7fc5b15 in __cxa_pure_virtual () from
>> /usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0
>> ---Type <return> to continue, or q <return> to quit---
>> #2576 0xb71d4491 in RTT::Logger::getLogModule() const () from
>> /usr/lib/liborocos-rtt-xenomai.so.1.8
>> #2577 0xb71d735e in RTT::Logger::In::In(std::string const&) () from
>> /usr/lib/liborocos-rtt-xenomai.so.1.8
>> #2578 0xb714e79f in RTT::ExecutionEngine::step() () from
>> /usr/lib/liborocos-rtt-xenomai.so.1.8
>> #2579 0xb725b301 in RTT::OS::RunnableInterface::loop() () from
>> /usr/lib/liborocos-rtt-xenomai.so.1.8
>> #2580 0xb723f1a8 in RTT::NonPeriodicActivity::loop() () from
>> /usr/lib/liborocos-rtt-xenomai.so.1.8
>> #2581 0xb725f662 in RTT::OS::singleThread_f(void*) () from
>> /usr/lib/liborocos-rtt-xenomai.so.1.8
>> #2582 0xb72635e5 in RTT::OS::detail::rtos_xeno_thread_wrapper(void*) ()
>> from /usr/lib/liborocos-rtt-xenomai.so.1.8
>> #2583 0xb8058525 in ?? () from /usr/lib/libnative.so.1
>> #2584 0x08c0d8d8 in ?? ()
>> #2585 0xb8057c30 in ?? () from /usr/lib/libnative.so.1
>> #2586 0xb40f43c4 in ?? ()
>> #2587 0xb55a2ea0 in ?? ()
>> #2588 0x00000001 in ?? ()
>> #2589 0x00000005 in ?? ()
>> #2590 0xb40f43c4 in ?? ()
>> #2591 0x08c0d63c in ?? ()
>> #2592 0x08c0d8f4 in ?? ()
>> #2593 0x00000062 in ?? ()
>> #2594 0x00000400 in ?? ()
>> #2595 0xb40f4b90 in ?? ()
>> #2596 0x0001022b in ?? ()
>> #2597 0x00000062 in ?? ()
>> #2598 0xb7263590 in ?? () from /usr/lib/liborocos-rtt-xenomai.so.1.8
>> #2599 0xb6f36ff4 in ?? () from /lib/libpthread.so.0
>> #2600 0xb40f4b90 in ?? ()
>> #2601 0x00000000 in ?? ()
>>
>>
>>
>> --
>> Carles Lopez
>> Senior Software Engineer
>>
>> Pal Robotics
>> http://www.pal-robotics.com
>> Tel: +34.93.414.53.47
>> Fax: +34.93.209.11.09
>>
>> c/ Pujades 77-79, 4t, 4-5
>> 08005 Barcelona
>
>
Is RTT::Logger thread safe?
On Mar 29, 2010, at 10:00 , Carles Lopez wrote:
> I can accept that the logger is not RT safe (and it's so clear in the
> documentation that it isn't) but it's more difficult to admit that
> it's not thread safe because.... well... the logger is extensively
> used inside RTT in RT threads for example. In particular, I'm worried
> about the use of the function RTT::Logger::In( const std::string&
> module ) because it's reassigning the internal std::string without
> using mayLog() to check for the log level.
There were some ML posts a long while back, maybe 2008 or early 2009, about use of Logger::In() and multiple threads. This is the non-thread safe part.
> Anyway, are you proposing that it's better compile all orocos with no Logger?
No. We use RTT::Logger, you just have to be aware that it is not real-time and that the as-logged Logger::In() values may be incorrect (we see this all the time).
I am actually working right now on backporting the new RT Logging infrastructure into v1 RTT::Logger. Will take some time to get this right though.
YMMV
Stephen
Is RTT::Logger thread safe?
> No. We use RTT::Logger, you just have to be aware that it is not real-time and that the as-logged Logger::In() values may be incorrect (we see this all the time).
I'm not concerned about the aesthetics issues of showing the incorrect
values in our logs but for the stability problems of our applications
due to this unsafe way to deal with std::strings. I attached here the
core dump generated for a suspicious double free in the RTT::Logger:
*** glibc detected *** /mnt_flash/bin/deployer-motor-xenomai: double
free or corruption (fasttop): 0x09e361d8 ***
======= Backtrace: =========
/lib/libc.so.6[0xb5d77c64]
/lib/libc.so.6(cfree+0x9c)[0xb5d795ac]
/usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0(_ZdlPv+0x21)[0xb7fce0b1]
/usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0(_ZNSs6assignERKSs+0x96)[0xb7fcb836]
/usr/lib/liborocos-rtt-xenomai.so.1.8(_ZN3RTT6Logger3outERKSs+0x47)[0xb720f4d7]
/usr/lib/liborocos-rtt-xenomai.so.1.8(_ZN3RTT6Logger2InD1Ev+0x2e)[0xb72116ce]
/usr/lib/liborocos-rtt-xenomai.so.1.8(_ZN3RTT15ExecutionEngine4stepEv+0x183)[0xb71898f3]
/usr/lib/liborocos-rtt-xenomai.so.1.8(_ZN3RTT16PeriodicActivity4stepEv+0x18)[0xb727bdc8]
/usr/lib/liborocos-rtt-xenomai.so.1.8(_ZN3RTT11TimerThread4stepEv+0x46)[0xb727edc6]
/usr/lib/liborocos-rtt-xenomai.so.1.8(_ZN3RTT2OS14periodicThreadEPv+0x230)[0xb7297eb0]
/usr/lib/liborocos-rtt-xenomai.so.1.8(_ZN3RTT2OS6detail24rtos_xeno_thread_wrapperEPv+0x55)[0xb729e405]
/usr/lib/libnative.so.1[0xb8063525]
/lib/libpthread.so.0[0xb6f620a5]
/lib/libc.so.6(clone+0x5e)[0xb5dd714e]
> I am actually working right now on backporting the new RT Logging infrastructure into v1 RTT::Logger. Will take some time to get this right though.
I was sure that new Logger will be a nice_to_have feature for next
versions of orocos but now it seems it's a must!
Is RTT::Logger thread safe?
On Monday 29 March 2010 17:28:12 Carles Lopez wrote:
> > No. We use RTT::Logger, you just have to be aware that it is not
> > real-time and that the as-logged Logger::In() values may be incorrect (we
> > see this all the time).
>
> I'm not concerned about the aesthetics issues of showing the incorrect
> values in our logs but for the stability problems of our applications
> due to this unsafe way to deal with std::strings. I attached here the
> core dump generated for a suspicious double free in the RTT::Logger:
>
> *** glibc detected *** /mnt_flash/bin/deployer-motor-xenomai: double
> free or corruption (fasttop): 0x09e361d8 ***
> ======= Backtrace: =========
> /lib/libc.so.6[0xb5d77c64]
> /lib/libc.so.6(cfree+0x9c)[0xb5d795ac]
> /usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0(_ZdlPv+0x21)[0xb7fce0b1]
> /usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0(_ZNSs6assignERKSs+0x96)[0x
> b7fcb836]
> /usr/lib/liborocos-rtt-xenomai.so.1.8(_ZN3RTT6Logger3outERKSs+0x47)[0xb720
> f4d7]
> /usr/lib/liborocos-rtt-xenomai.so.1.8(_ZN3RTT6Logger2InD1Ev+0x2e)[0xb72116
> ce]
> /usr/lib/liborocos-rtt-xenomai.so.1.8(_ZN3RTT15ExecutionEngine4stepEv+0x18
> 3)[0xb71898f3]
> /usr/lib/liborocos-rtt-xenomai.so.1.8(_ZN3RTT16PeriodicActivity4stepEv+0x1
> 8)[0xb727bdc8]
> /usr/lib/liborocos-rtt-xenomai.so.1.8(_ZN3RTT11TimerThread4stepEv+0x46)[0x
> b727edc6]
> /usr/lib/liborocos-rtt-xenomai.so.1.8(_ZN3RTT2OS14periodicThreadEPv+0x230)
> [0xb7297eb0]
> /usr/lib/liborocos-rtt-xenomai.so.1.8(_ZN3RTT2OS6detail24rtos_xeno_thread_
> wrapperEPv+0x55)[0xb729e405] /usr/lib/libnative.so.1[0xb8063525]
> /lib/libpthread.so.0[0xb6f620a5]
> /lib/libc.so.6(clone+0x5e)[0xb5dd714e]
How could you reproduce this ? Does it occur each time ?
>
> > I am actually working right now on backporting the new RT Logging
> > infrastructure into v1 RTT::Logger. Will take some time to get this right
> > though.
>
> I was sure that new Logger will be a nice_to_have feature for next
> versions of orocos but now it seems it's a must!
The Logger::In statement must be removed from the ExecutionEngine. It was
meant to improve debugging log messages to see from which component they came,
but as pointed out, it is not guaranteed real-time and not thread-safe.
Peter
Is RTT::Logger thread safe?
Unfortunately I don't have a specific test for that. I saw it
intermittently. We're using now three different processes connected by
Corba. It's more likely to occur at the beginning of the connection
between components of different processes but maybe it's a bias :(
We have a high frequency activity (100~200Hz) with, in the worst case,
250 DataPorts plus 2 components connected in the same processes and
6~8 different components connected to it with Corba.
For me now, it's quicker and more useful to totally remove the support
inside logger for the information about the module name. It's a
question of aesthetics against reliability.
On Tue, Mar 30, 2010 at 09:16, Peter Soetens <peter [dot] soetens [..] ...> wrote:
> On Monday 29 March 2010 17:28:12 Carles Lopez wrote:
>> > No. We use RTT::Logger, you just have to be aware that it is not
>> > real-time and that the as-logged Logger::In() values may be incorrect (we
>> > see this all the time).
>>
>> I'm not concerned about the aesthetics issues of showing the incorrect
>> values in our logs but for the stability problems of our applications
>> due to this unsafe way to deal with std::strings. I attached here the
>> core dump generated for a suspicious double free in the RTT::Logger:
>>
>> *** glibc detected *** /mnt_flash/bin/deployer-motor-xenomai: double
>> free or corruption (fasttop): 0x09e361d8 ***
>> ======= Backtrace: =========
>> /lib/libc.so.6[0xb5d77c64]
>> /lib/libc.so.6(cfree+0x9c)[0xb5d795ac]
>> /usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0(_ZdlPv+0x21)[0xb7fce0b1]
>> /usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0(_ZNSs6assignERKSs+0x96)[0x
>> b7fcb836]
>> /usr/lib/liborocos-rtt-xenomai.so.1.8(_ZN3RTT6Logger3outERKSs+0x47)[0xb720
>> f4d7]
>> /usr/lib/liborocos-rtt-xenomai.so.1.8(_ZN3RTT6Logger2InD1Ev+0x2e)[0xb72116
>> ce]
>> /usr/lib/liborocos-rtt-xenomai.so.1.8(_ZN3RTT15ExecutionEngine4stepEv+0x18
>> 3)[0xb71898f3]
>> /usr/lib/liborocos-rtt-xenomai.so.1.8(_ZN3RTT16PeriodicActivity4stepEv+0x1
>> 8)[0xb727bdc8]
>> /usr/lib/liborocos-rtt-xenomai.so.1.8(_ZN3RTT11TimerThread4stepEv+0x46)[0x
>> b727edc6]
>> /usr/lib/liborocos-rtt-xenomai.so.1.8(_ZN3RTT2OS14periodicThreadEPv+0x230)
>> [0xb7297eb0]
>> /usr/lib/liborocos-rtt-xenomai.so.1.8(_ZN3RTT2OS6detail24rtos_xeno_thread_
>> wrapperEPv+0x55)[0xb729e405] /usr/lib/libnative.so.1[0xb8063525]
>> /lib/libpthread.so.0[0xb6f620a5]
>> /lib/libc.so.6(clone+0x5e)[0xb5dd714e]
>
> How could you reproduce this ? Does it occur each time ?
>
>>
>> > I am actually working right now on backporting the new RT Logging
>> > infrastructure into v1 RTT::Logger. Will take some time to get this right
>> > though.
>>
>> I was sure that new Logger will be a nice_to_have feature for next
>> versions of orocos but now it seems it's a must!
>
> The Logger::In statement must be removed from the ExecutionEngine. It was
> meant to improve debugging log messages to see from which component they came,
> but as pointed out, it is not guaranteed real-time and not thread-safe.
>
> Peter
>
Is RTT::Logger thread safe?
On Mar 29, 2010, at 11:28 , Carles Lopez wrote:
>> No. We use RTT::Logger, you just have to be aware that it is not real-time and that the as-logged Logger::In() values may be incorrect (we see this all the time).
>
> I'm not concerned about the aesthetics issues of showing the incorrect
> values in our logs but for the stability problems of our applications
> due to this unsafe way to deal with std::strings. I attached here the
> core dump generated for a suspicious double free in the RTT::Logger:
>
> *** glibc detected *** /mnt_flash/bin/deployer-motor-xenomai: double
> free or corruption (fasttop): 0x09e361d8 ***
> ======= Backtrace: =========
> /lib/libc.so.6[0xb5d77c64]
> /lib/libc.so.6(cfree+0x9c)[0xb5d795ac]
> /usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0(_ZdlPv+0x21)[0xb7fce0b1]
> /usr/lib/libboost_system-gcc43-mt-1_38.so.1.38.0(_ZNSs6assignERKSs+0x96)[0xb7fcb836]
> /usr/lib/liborocos-rtt-xenomai.so.1.8(_ZN3RTT6Logger3outERKSs+0x47)[0xb720f4d7]
> /usr/lib/liborocos-rtt-xenomai.so.1.8(_ZN3RTT6Logger2InD1Ev+0x2e)[0xb72116ce]
> /usr/lib/liborocos-rtt-xenomai.so.1.8(_ZN3RTT15ExecutionEngine4stepEv+0x183)[0xb71898f3]
> /usr/lib/liborocos-rtt-xenomai.so.1.8(_ZN3RTT16PeriodicActivity4stepEv+0x18)[0xb727bdc8]
> /usr/lib/liborocos-rtt-xenomai.so.1.8(_ZN3RTT11TimerThread4stepEv+0x46)[0xb727edc6]
> /usr/lib/liborocos-rtt-xenomai.so.1.8(_ZN3RTT2OS14periodicThreadEPv+0x230)[0xb7297eb0]
> /usr/lib/liborocos-rtt-xenomai.so.1.8(_ZN3RTT2OS6detail24rtos_xeno_thread_wrapperEPv+0x55)[0xb729e405]
> /usr/lib/libnative.so.1[0xb8063525]
> /lib/libpthread.so.0[0xb6f620a5]
> /lib/libc.so.6(clone+0x5e)[0xb5dd714e]
Can't help you with this one. Does point suspiciously to Logger::In doesn't it ...
>> I am actually working right now on backporting the new RT Logging infrastructure into v1 RTT::Logger. Will take some time to get this right though.
> I was sure that new Logger will be a nice_to_have feature for next
> versions of orocos but now it seems it's a must!
Funny you mention that ... I've fought here for a while that it is a must_have feature, but only just recently it turned into a must_have_now feature due to RTT::Logger issues. They say that "necessity is the mother of all invention" ... in the software world I would add "frustration is often the cause of invention", or something similar ... :-)
YMMV
Stephen
Is RTT::Logger thread safe?
> Funny you mention that ... I've fought here for a while that it is a must_have feature, but only just recently it turned into a must_have_now feature due to RTT::Logger issues. They say that "necessity is the mother of all invention" ... in the software world I would add "frustration is often the cause of invention", or something similar ... :-)
Strange... I heard some time before that the invention was the cause
of frustration ;-)