Hello,
I'm not sure this is a bug or I misunderstand something. I have Orocos-RTT
2.3.1 compiled with RT_MALLOC enabled. I have this simple test case:
#include <rtt/TaskContext.hpp> #include <rtt/Property.hpp> #include <rtt/Operation.hpp> #include <rtt/Port.hpp> #include <rtt/RTT.hpp> class PingTaskContext : public RTT::TaskContext { public: void ping() { } PingTaskContext(const std::string &name) : RTT::TaskContext(name) { this->addOperation("pingClientThread", &PingTaskContext::ping, this, RTT::ClientThread).doc("Ping using the client thread."); this->addOperation("pingOwnThread", &PingTaskContext::ping, this, RTT::OwnThread).doc("Ping using the component thread."); } virtual ~PingTaskContext() {} }; int main(int argc, char* argv[]) { PingTaskContext ptc("ptc"); ptc.setActivity(new RTT::Activity(5, 0.01)); // Test call to pingClientThread through an OperationCaller RTT::OperationCaller<void(void)> pingClientThread = ptc.getOperation("pingClientThread"); pingClientThread(); // OK // Test call to pingOwnThread through an OperationCaller RTT::OperationCaller<void(void)> pingOwnThread = ptc.getOperation("pingOwnThread"); pingOwnThread(); // SEGFAULT }
The application generates a segmentation fault when calling pingOwnThread().
Here is the backtrace:
#0 0x00007ffff6edf3c4 in pthread_mutex_lock () from /lib/libpthread.so.0 #1 0x00007ffff6c2f694 in rtos_mutex_lock (size=184) at /usr/local/src/orocos-toolchain-2.3.1/rtt/rtt/os/tlsf/../gnulinux/fosi.h:237 #2 oro_rt_malloc (size=184) at /usr/local/src/orocos-toolchain-2.3.1/rtt/rtt/os/tlsf/tlsf.c:631 #3 0x00000000004429b0 in RTT::os::rt_allocator<boost::detail::sp_counted_impl_pda<RTT::internal::LocalOperationCaller<void ()()>*, boost::detail::sp_ms_deleter<RTT::internal::LocalOperationCaller<void ()()> >, RTT::os::rt_allocator<RTT::internal::LocalOperationCaller<void ()()> > > >::allocate(unsigned long, boost::detail::sp_counted_impl_pda<RTT::internal::LocalOperationCaller<void ()()>*, boost::detail::sp_ms_deleter<RTT::internal::LocalOperationCaller<void ()()> >, RTT::os::rt_allocator<RTT::internal::LocalOperationCaller<void ()()> > > const*) (this=0x7fffffffdeff, n=1) at /usr/local/include/rtt/internal/../internal/../os/oro_allocator.hpp:276 #4 0x0000000000441557 in shared_count<RTT::internal::LocalOperationCaller<void()>*, boost::detail::sp_ms_deleter<RTT::internal::LocalOperationCaller<void()> >, RTT::os::rt_allocator<RTT::internal::LocalOperationCaller<void()> > > ( this=0x7fffffffe0d8, p=0x0, d=..., a=...) at /usr/include/boost/smart_ptr/detail/shared_count.hpp:159 #5 0x000000000043fee3 in shared_ptr<RTT::internal::LocalOperationCaller<void()>, boost::detail::sp_ms_deleter<RTT::internal::LocalOperationCaller<void()> >, RTT::os::rt_allocator<RTT::internal::LocalOperationCaller<void()> > > ( this=0x7fffffffe0d0, p=0x0, d=..., a=...) at /usr/include/boost/smart_ptr/shared_ptr.hpp:205 #6 0x000000000043df36 in boost::shared_ptr<RTT::internal::LocalOperationCaller<void ()()> > boost::allocate_shared<RTT::internal::LocalOperationCaller<void ()()>, RTT::os::rt_allocator<RTT::internal::LocalOperationCaller<void ()()> >, RTT::internal::LocalOperationCaller<void ()()> >(RTT::os::rt_allocator<RTT::internal::LocalOperationCaller<void ()()> > const&, RTT::internal::LocalOperationCaller<void ()()> const&) (a=..., a1=...) at /usr/include/boost/smart_ptr/make_shared.hpp:197 #7 0x000000000043c9d8 in RTT::internal::LocalOperationCaller<void ()()>::cloneRT() const (this=0x6614d0) at /usr/local/include/rtt/internal/../internal/LocalOperationCaller.hpp:666 #8 0x000000000043db7d in RTT::internal::LocalOperationCallerImpl<void ()()>::send_impl() (this=0x6614d0) at /usr/local/include/rtt/internal/../internal/LocalOperationCaller.hpp:166 #9 0x000000000043dc14 in RTT::internal::LocalOperationCallerImpl<void ()()>::call_impl() (this=0x6614d0) at /usr/local/include/rtt/internal/../internal/LocalOperationCaller.hpp:327 #10 0x000000000043c1f0 in RTT::internal::InvokerImpl<0, void ()(), RTT::internal::LocalOperationCallerImpl<void ()()> >::call() (this=0x6614d0) at /usr/local/include/rtt/internal/../internal/Invoker.hpp:75 #11 0x00000000004352d0 in RTT::internal::InvokerSignature<0, void ()(), boost::shared_ptr<RTT::base::OperationCallerBase<void ()()> > >::operator()() (this=0x7fffffffe348) at /usr/local/include/rtt/internal/InvokerSignature.hpp:75 #12 0x0000000000433dcb in main (argc=1, argv=0x7fffffffe618) at /home/hamelinp/devroot/SM/trunk/libs/orocos-utils/test/testSMTaskContext/testSMTaskContext.cpp:144
It crashed in oro_rt_malloc so I initialized the memory pool
(init_memory_pool) and the problem is fixed. Why does calling an operation
in the component thread require to initialize the TSLF memory pool?
Philippe
Segfault when calling an operation in OwnThread without TSLF ini
2011/6/9 Philippe Hamelin <philippe [dot] hamelin [..] ...>
> Hello,
>
> I'm not sure this is a bug or I misunderstand something. I have Orocos-RTT
> 2.3.1 compiled with RT_MALLOC enabled. I have this simple test case:
>
>
>
> The application generates a segmentation fault when
> calling pingOwnThread(). Here is the backtrace:
>
>
>
> It crashed in oro_rt_malloc so I initialized the memory pool
> (init_memory_pool) and the problem is fixed. Why does calling an operation
> in the component thread require to initialize the TSLF memory pool?
>
>
>
Ok I found why this is happening. The cloneRT() method, which seems to be
used for OperationCaller, makes use of the rt_allocator :
So that means that if Orocos-RTT is compiled with RT_MALLOC support one
should always initialize the memory pool before doing anything. I thought
wrongly that TLSF was only used for real-time logging. This leads me to ask
some questions:
1. Is this documented somewhere?
2. Does ORO_main should do some default initialization (letting the user to
resize it afterwhile) of the memory pool if no parameters are given on the
command line?
3. Shouldn't we put a big assert in the rt_malloc if no memory pool is
initialized?
4. Is there a define that tell me that TSLF is enabled in RTT such that I
need to initialize the memory pool?
Philippe
Segfault when calling an operation in OwnThread without TSLF ini
On Thu, Jun 9, 2011 at 5:34 PM, Philippe Hamelin
<philippe [dot] hamelin [..] ...> wrote:
...
> 2011/6/9 Philippe Hamelin <philippe [dot] hamelin [..] ...>
>> It crashed in oro_rt_malloc so I initialized the memory pool
>> (init_memory_pool) and the problem is fixed. Why does calling an operation
>> in the component thread require to initialize the TSLF memory pool?
>>
>
> Ok I found why this is happening. The cloneRT() method, which seems to be
> used for OperationCaller, makes use of the rt_allocator :
>
> So that means that if Orocos-RTT is compiled with RT_MALLOC support one
> should always initialize the memory pool before doing anything. I thought
> wrongly that TLSF was only used for real-time logging. This leads me to ask
> some questions:
> 1. Is this documented somewhere?
It's enabled when using the deployers and can be configured using a command
line option. It's not documented...
> 2. Does ORO_main should do some default initialization (letting the user to
> resize it afterwhile) of the memory pool if no parameters are given on the
> command line?
That code in the deployer could move to ORO_main... but it's some work since
we also want to have the options show up when the program is run with
--help, ie, using boost::program_options
> 3. Shouldn't we put a big assert in the rt_malloc if no memory pool is
> initialized?
It should at least return NULL and not crash. We should log an error when no
initialisation has been done, since this is in most cases a user bug.
> 4. Is there a define that tell me that TSLF is enabled in RTT such that I
> need to initialize the memory pool?
See OCL's deployer.cpp for the logic we use...
> Philippe
>
>
Peter
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
Segfault when calling an operation in OwnThread without TSLF ini
2011/6/9 Philippe Hamelin <philippe [dot] hamelin [..] ...>
> 2011/6/9 Philippe Hamelin <philippe [dot] hamelin [..] ...>
>
>> Hello,
>>
>> I'm not sure this is a bug or I misunderstand something. I have Orocos-RTT
>> 2.3.1 compiled with RT_MALLOC enabled. I have this simple test case:
>>
>>
>>
>> The application generates a segmentation fault when
>> calling pingOwnThread(). Here is the backtrace:
>>
>>
>>
>> It crashed in oro_rt_malloc so I initialized the memory pool
>> (init_memory_pool) and the problem is fixed. Why does calling an operation
>> in the component thread require to initialize the TSLF memory pool?
>>
>>
>>
> Ok I found why this is happening. The cloneRT() method, which seems to be
> used for OperationCaller, makes use of the rt_allocator :
>
>
>
> So that means that if Orocos-RTT is compiled with RT_MALLOC support one
> should always initialize the memory pool before doing anything. I thought
> wrongly that TLSF was only used for real-time logging. This leads me to ask
> some questions:
>
> 1. Is this documented somewhere?
> 2. Does ORO_main should do some default initialization (letting the user to
> resize it afterwhile) of the memory pool if no parameters are given on the
> command line?
> 3. Shouldn't we put a big assert in the rt_malloc if no memory pool is
> initialized?
> 4. Is there a define that tell me that TSLF is enabled in RTT such that I
> need to initialize the memory pool?
>
>
#4 is answered. I found that there's a define available through
rtt-config.h, which is OS_RT_MALLOC.
Philippe
Segfault when calling an operation in OwnThread without TSLF ini
On Jun 9, 2011, at 13:02 , Philippe Hamelin wrote:
> 2011/6/9 Philippe Hamelin <philippe [dot] hamelin [..] ...>
> 2011/6/9 Philippe Hamelin <philippe [dot] hamelin [..] ...>
> Hello,
>
> I'm not sure this is a bug or I misunderstand something. I have Orocos-RTT 2.3.1 compiled with RT_MALLOC enabled. I have this simple test case:
>
>
>
> The application generates a segmentation fault when calling pingOwnThread(). Here is the backtrace:
>
>
>
> It crashed in oro_rt_malloc so I initialized the memory pool (init_memory_pool) and the problem is fixed. Why does calling an operation in the component thread require to initialize the TSLF memory pool?
>
>
>
> Ok I found why this is happening. The cloneRT() method, which seems to be used for OperationCaller, makes use of the rt_allocator :
>
>
>
> So that means that if Orocos-RTT is compiled with RT_MALLOC support one should always initialize the memory pool before doing anything. I thought wrongly that TLSF was only used for real-time logging. This leads me to ask some questions:
This is actually news to me ... but it doesn't surprise me.
> 1. Is this documented somewhere?
AFAIK the only documentation related to TLSF (and real-time logging) is the logging page I created on the wiki ...?
> 2. Does ORO_main should do some default initialization (letting the user to resize it afterwhile) of the memory pool if no parameters are given on the command line?
Yes it should, same as with the OCL deployer (or in reality, the deployer TLSF init code should go _in_ RTT)? That uses a cmake-time constant for the default memory pool size, which the user can obviously override.
> 3. Shouldn't we put a big assert in the rt_malloc if no memory pool is initialized?
If it _truly is_ a requirement for RTT, then something should occur to warn the user. Or do the above?
> 4. Is there a define that tell me that TSLF is enabled in RTT such that I need to initialize the memory pool?
>
>
> #4 is answered. I found that there's a define available through rtt-config.h, which is OS_RT_MALLOC.
What I'm getting from this is that few people out there are actually using TLSF and/or the real-time logging in RTT?
Sorry that is happening to you Philippe, it's just that we've been using TLSF and the real-time logging for so long based on a customized RTT/OCL v1, that we simply don't have any experience using it with v2. And we've also laxed in providing examples of how to do it ... :-(
S
Segfault when calling an operation in OwnThread without TSLF ini
2011/6/9 S Roderick <kiwi [dot] net [..] ...>
> On Jun 9, 2011, at 13:02 , Philippe Hamelin wrote:
>
> > 2011/6/9 Philippe Hamelin <philippe [dot] hamelin [..] ...>
> > 2011/6/9 Philippe Hamelin <philippe [dot] hamelin [..] ...>
> > Hello,
> >
> > I'm not sure this is a bug or I misunderstand something. I have
> Orocos-RTT 2.3.1 compiled with RT_MALLOC enabled. I have this simple test
> case:
> >
> >
> >
> > The application generates a segmentation fault when calling
> pingOwnThread(). Here is the backtrace:
> >
> >
> >
> > It crashed in oro_rt_malloc so I initialized the memory pool
> (init_memory_pool) and the problem is fixed. Why does calling an operation
> in the component thread require to initialize the TSLF memory pool?
> >
> >
> >
> > Ok I found why this is happening. The cloneRT() method, which seems to be
> used for OperationCaller, makes use of the rt_allocator :
> >
> >
> >
> > So that means that if Orocos-RTT is compiled with RT_MALLOC support one
> should always initialize the memory pool before doing anything. I thought
> wrongly that TLSF was only used for real-time logging. This leads me to ask
> some questions:
>
> This is actually news to me ... but it doesn't surprise me.
>
> > 1. Is this documented somewhere?
>
> AFAIK the only documentation related to TLSF (and real-time logging) is the
> logging page I created on the wiki ...?
>
> > 2. Does ORO_main should do some default initialization (letting the user
> to resize it afterwhile) of the memory pool if no parameters are given on
> the command line?
>
> Yes it should, same as with the OCL deployer (or in reality, the deployer
> TLSF init code should go _in_ RTT)? That uses a cmake-time constant for the
> default memory pool size, which the user can obviously override.
>
> > 3. Shouldn't we put a big assert in the rt_malloc if no memory pool is
> initialized?
>
> If it _truly is_ a requirement for RTT, then something should occur to warn
> the user. Or do the above?
>
> > 4. Is there a define that tell me that TSLF is enabled in RTT such that I
> need to initialize the memory pool?
> >
> >
> > #4 is answered. I found that there's a define available through
> rtt-config.h, which is OS_RT_MALLOC.
>
> What I'm getting from this is that few people out there are actually using
> TLSF and/or the real-time logging in RTT?
>
> Sorry that is happening to you Philippe, it's just that we've been using
> TLSF and the real-time logging for so long based on a customized RTT/OCL v1,
> that we simply don't have any experience using it with v2. And we've also
> laxed in providing examples of how to do it ... :-(
>
We are using TLSF + real-time logging for some months in v2.x, but I've
never faced the problem of having an OperationCaller + no TSLF initialized
since today.
Philippe
Segfault when calling an operation in OwnThread without TSLF ini
On Thu, Jun 9, 2011 at 5:07 PM, Philippe Hamelin <philippe [dot] hamelin [..] ...
> wrote:
> Hello,
>
> I'm not sure this is a bug or I misunderstand something. I have Orocos-RTT
> 2.3.1 compiled with RT_MALLOC enabled. I have this simple test case:
>
>
>
> The application generates a segmentation fault when
> calling pingOwnThread(). Here is the backtrace:
>
>
>
> It crashed in oro_rt_malloc so I initialized the memory pool
> (init_memory_pool) and the problem is fixed. Why does calling an operation
> in the component thread require to initialize the TSLF memory pool?
>
> Philippe
>
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
>
Segfault when calling an operation in OwnThread without TSLF ini
On Jun 9, 2011, at 11:24 , Adolfo Rodríguez Tsouroukdissian wrote:
>
>
> On Thu, Jun 9, 2011 at 5:07 PM, Philippe Hamelin <philippe [dot] hamelin [..] ...> wrote:
> Hello,
>
> I'm not sure this is a bug or I misunderstand something. I have Orocos-RTT 2.3.1 compiled with RT_MALLOC enabled. I have this simple test case:
>
>
>
> The application generates a segmentation fault when calling pingOwnThread(). Here is the backtrace:
>
>
>
> It crashed in oro_rt_malloc so I initialized the memory pool (init_memory_pool) and the problem is fixed. Why does calling an operation in the component thread require to initialize the TSLF memory pool?
>
> Philippe
>
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
>
>
>
Segfault when calling an operation in OwnThread without TSLF ini
2011/6/9 Adolfo Rodríguez Tsouroukdissian <adolfo [dot] rodriguez [..] ...
>
>
>
> On Thu, Jun 9, 2011 at 5:07 PM, Philippe Hamelin <
> philippe [dot] hamelin [..] ...> wrote:
>
>> Hello,
>>
>> I'm not sure this is a bug or I misunderstand something. I have Orocos-RTT
>> 2.3.1 compiled with RT_MALLOC enabled. I have this simple test case:
>>
>>
>>
>> The application generates a segmentation fault when
>> calling pingOwnThread(). Here is the backtrace:
>>
>>
>>
>> It crashed in oro_rt_malloc so I initialized the memory pool
>> (init_memory_pool) and the problem is fixed. Why does calling an operation
>> in the component thread require to initialize the TSLF memory pool?
>>
>> Philippe
>>
>>
>> --
>> Orocos-Dev mailing list
>> Orocos-Dev [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>>
>>
>
>
> --
> Adolfo Rodríguez Tsouroukdissian
>
> Robotics engineer
> PAL ROBOTICS S.L
> http://www.pal-robotics.com
> Tel. +34.93.414.53.47
> Fax.+34.93.209.11.09
>
> CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may
> contain confidential information which is privileged and intended only for
> the individual or entity to whom they are addressed. If you are not the
> intended recipient, you are hereby notified that any disclosure, copying,
> distribution or use of this e-mail and/or accompanying document(s) is
> strictly prohibited. If you have received this e-mail in error, please
> immediately notify the sender at the above e-mail address.
>