On Tuesday 01 March 2011 10:05:57 Dominick Vanthienen wrote:
> On 02/28/2011 08:41 PM, Willy Lambert wrote:
> > 2011/2/28 Peter Soetens <peter [..] ...
> > <mailto:peter [..] ...>>
> >
> > On Mon, Feb 28, 2011 at 6:48 PM, Dominick Vanthienen
> >
> > <dominick [dot] vanthienen [..] ...
dominick [dot] vanthienen [..] ...>> wrote:
> > > Dear all,
> > > I've a component that has to set some the value of some attributes
> > > of another component. The attributes of this 2nd component are
> > > created in the configure hook (once we know how many ther are to
> > > be created). When calling the attribute and asking whether he's
> > > ready: no problems, everything fine BUT when trying to get or set
> > > the value (in any order) it gives a segmentation fault.
> > >
> > > Similar code works fine, only difference: attributes are defined in
> > > the normal way: at construction time not in the configureHook
> > > There are multiple examples where ports are created in the
> > > configureHook.
> > >
> > > Is it not possible to create attributes/properties in the
> > > configureHook???
> >
> > It is, but your server-side code is wrong. It takes a reference to
> > your attribute object. If that lives
> > on the stack of your configureHook(), any code that tries to access
> > it will crash, as your bt shows.
> >
> > Write in configureHook() : provides()->setValue( new
> > Attribute<double>( x ) );
>
> This was not the problem, it is the following:
>
> MY COMPONENT THAT HAS THE ATTRIBUTE I WANT TO SET:
> //(in the HPP)
> std::vector<Priority*> priorities;
> struct Priority
> {
> public:
> unsigned int nc_priority;
> RTT::InputPort<Eigen::MatrixXd> A_port;
> }
>
> //(in the CPP)
> bool WDLSPriorVelSolver::configureHook()
> {
> priorities.resize(priorityNo) ;
> for (unsigned int i=0;i<priorityNo;i++)
> {
> //create attributes
> ssName.clear();
> ssName << "nc_" << i+1;
> ssName >> externalName;
>
> this->provides()->addAttribute(externalName,priorities[i]->nc_priority);
> => by changing priorities[i]->nc_priority to a normal variable, it
> works!!! //this->provides()->setValue( new Attribute<unsigned
> int>(externalName,priorities[i]->nc_priority) ); => this doesn't work
> either }
> return true;
> }

Your problem is that you take a reference to the contents of an std::vector.
Each time the vector is changed, all references are invalidated, and your
attribute points to 'dead' memory. That it works with std::map is because the
map's iterators are not invalidated because of an insert, but frankly, even
that is very close to playing with fire. It *might* no longer work in a future
upgrade, or when you switch to another compiler.

>
> But in the iTaSC implementation, something similar works already, with the
> difference that there is a map of tasks in stead of a vector of
> priorities! (already in RTT1.10, see example at our public repos:
> http://svn.mech.kuleuven.be/repos/orocos/trunk/kul-ros-pkg/iTaSC/src/Scene
> .hpp look for the task or robot struct) The same problem occurs with the
> A_port creation, which is created with:
>
> //create ports
> ssName.clear();
> ssName << "A_" << i+1;
> ssName >> externalName;
> this->ports()->addPort(externalName, priorities[i]->A_port).doc("blabla");

What does a valgrind run say ? Doesn't it complain that the attribute or port
is referring to a 'freed' memory block ? That would support my hypothesis.

I'm not saying that you can't store ports or attributes in an std::vector. You
just have to make sure that it is never mutated anymore, once you did so.

>
> > > Can anyone point me out to the source of the problem and suggest a
> > > solution?
> > >
> > > Thanks a lot,
> > > Nick
> > >
> > > THE CODE
> > > Attribute<unsigned int> nc;
> > > log(Info) << "nc ready?= " << nc.ready() << endlog(); => returns 0
> > > as expected for (unsigned int i=0;i<priorities.size();i++)
> > > {
> > >
> > > log(Info) << "loop i = " << i << endlog();
> > > //set the attributes
> > > ssName.clear();
> > > ssName << "nc_" << i+1;
> > > ssName >> externalName;
> > > nc = peer->provides()->getAttribute(externalName);
> > > log(Info) << "nc_i = " << externalName << endlog();
> > > if(!nc.ready())
> > > {
> > >
> > > log(Error) << "Attribute nc_" << i+1 << " of the
> > > Solver is not ready." << endlog(); return false;
> > >
> > > }
> > > log(Info) << "nc ready?= " << nc.ready() << endlog(); =>
> > > says it's ready log(Info) << "nc value to set= " <<
> > > priorities[i]->nc_priority << endlog(); => 6 in this case,
> > > which is an unsigned int log(Info) << "nc value (get)=
> > > "<<nc.get()< > > > nc.set(priorities[i]->nc_priority); => SEGFAULT
> > > log(Info) << "nc set" << endlog();
> > >
> > > }
> > >
> > > a BT of the segcault:
> > >
> > > 6.185 [ Info ][Scene] nc ready?= 0
> > > 6.185 [ Info ][Scene] loop i = 0
> > > 6.185 [ Info ][Scene] nc_i = nc_1
> > > 6.185 [ Info ][Scene] nc ready?= 1
> > > 6.185 [ Info ][Scene] nc value to set= 6
> > >
> > > Program received signal SIGSEGV, Segmentation fault.
> > > 0xb6fa085a in RTT::internal::ReferenceDataSource<unsigned int>::get
> > > (this=0xbfffd87c)
> > >
> > > at
> > >
> > > /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/r
> > > tt/rtt/typekit/../types/../internal/DataSources.hpp:225 225
> > > typename DataSource<T>::result_t get() const (gdb) bt
> > > #0 0xb6fa085a in RTT::internal::ReferenceDataSource<unsigned
> > > int>::get (this=0xbfffd87c)
> > >
> > > at
> > >
> > > /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/r
> > > tt/rtt/typekit/../types/../internal/DataSources.hpp:225 #1
> > > 0xb2c990d1 in iTaSC::ScenePriorities::addSolver (this=0x80ccdc0,
> > > PeerName=...)
> > >
> > > at
> > >
> > > /home/u0065688/src/svn/robotics-ros/packages/private-kul-ros-pkg/iT
> > > aSC/src/ScenePriorities.cpp:533 #2 0xb2c968cc in
> > > iTaSC::ScenePriorities::configureHook (this=0x80ccdc0)
> > >
> > > at
> > >
> > > /home/u0065688/src/svn/robotics-ros/packages/private-kul-ros-pkg/iT
> > > aSC/src/ScenePriorities.cpp:243 #3 0xb7eef0d7 in
> > > RTT::base::TaskCore::configure (this=0x80ccdc0) at
> > > /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/
> > > rtt/rtt/base/TaskCore.cpp:107 #4 0xb7e856ea in
> > > call<RTT::TaskContext*> (function_obj_ptr=...) at
> > > /usr/include/boost/bind/mem_fn_template.hpp:40
> > > #5 operator()<RTT::TaskContext*> (function_obj_ptr=...) at
> > > /usr/include/boost/bind/mem_fn_template.hpp:55
> > > #6 operator()<bool, boost::_mfi::mf0 > > > boost::_bi::list0> (function_obj_ptr=...) at
> > > /usr/include/boost/bind/bind.hpp:243
> > > #7 operator() (function_obj_ptr=...) at
> > > /usr/include/boost/bind/bind_template.hpp:20
> > > #8
> > > boost::detail::function::function_obj_invoker0<boost::_bi::bind_t > > > oost::_bi::unspecified, boost::_mfi::mf0<bool,
> > > RTT::base::TaskCore>,
> > > boost::_bi::list1<boost::_bi::value > > > bool>::invoke (function_obj_ptr=...) at
> > > /usr/include/boost/function/function_template.hpp:132
> > > #9 0xb7e9dbac in RTT::internal::InvokerImpl<0, bool ()(),
> > > RTT::internal::LocalOperationCallerImpl<bool ()()> >::call() ()
> > >
> > > from
> > >
> > > /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/r
> > > tt/install/lib/liborocos-rtt-gnulinux.so.2.2 #10 0xb7e87413 in
> > > call<bool
> > > (RTT::base::OperationCallerBase<bool()>::*)()> (f=&virtual table
> > > offset 12, s=...)
> > >
> > > at
> > > /usr/include/boost/fusion/functional/invocation/invoke.hpp:279
> > >
> > > #11 boost::fusion::invoke<bool
> > > (RTT::base::OperationCallerBase<bool()>::*)(),
> > > boost::fusion::cons<RTT::base::OperationCallerBase > > > boost::fusion::vector<boost::fusion::void_, boost::fusion::void_,
> > > boost::fusion::void_, boost::fusion::void_, boost::fusion::void_,
> > > boost::fusion::void_, boost::fusion::void_, boost::fusion::void_,
> > > boost::fusion::void_, boost::fusion::void_> > >(bool
> > > (RTT::base::OperationCallerBase<bool()>::*)(RTT::base::OperationCal
> > > lerBase<bool()> *), const
> > > boost::fusion::cons<RTT::base::OperationCallerBase > > > boost::fusion::vector<boost::fusion::void_, boost::fusion::void_,
> > > boost::fusion::void_, boost::fusion::void_, boost::fusion::void_,
> > > boost::fusion::void_, boost::fusion::void_, boost::fusion::void_,
> > > boost::fusion::void_, boost::fusion::void_> > &) (f=&virtual table
> > > offset 12, s=...)
> > >
> > > at
> > > /usr/include/boost/fusion/functional/invocation/invoke.hpp:178
> > >
> > > #12 0xb7e86fb0 in operator()<bool,
> > > RTT::internal::FusedMCallDataSource::evaluate::iret (*)(bool
> > > (RTT::base::OperationCallerBase<bool()>::*)(), const
> > > RTT::internal::FusedMCallDataSource<Signature>::evaluate() const
> > > [with Signature = bool()]::arg_type&), boost::_bi::list0>
> > > (this=0x80f5f38) at /usr/include/boost/bind/bind.hpp:303
> > > #13 operator() (this=0x80f5f38) at
> > > /usr/include/boost/bind/bind_template.hpp:20
> > > #14 exec<boost::_bi::bind_t > > > RTT::internal::FusedMCallDataSource::evaluate::iret (*)(bool
> > > (RTT::base::OperationCallerBase<bool()>::*)(), const
> > > RTT::internal::FusedMCallDataSource<Signature>::evaluate() const
> > > [with Signature = bool()]::arg_type&),
> > > boost::_bi::list2<boost::_bi::value > > > (RTT::internal::InvokerBaseImpl<0, bool()>::*)()>,
> > > boost::_bi::value<boost::fusion::cons > > > e<bool()>*, boost::fusion::vector<boost::fusion::void_,
> > > boost::fusion::void_, boost::fusion::void_, boost::fusion::void_,
> > > boost::fusion::void_, boost::fusion::void_, boost::fusion::void_,
> > > boost::fusion::void_, boost::fusion::void_, boost::fusion::void_>
> > > > > > > > (
> > >
> > > this=0x80f5f38) at
> > >
> > > /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/r
> > > tt/rtt/internal/BindStorage.hpp:121 #15
> > > RTT::internal::FusedMCallDataSource<bool()>::evaluate(void) const
> > > (this=0x80f5f38)
> > >
> > > at
> > >
> > > /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/r
> > > tt/rtt/internal/FusedFunctorDataSource.hpp:298 #16 0xb76db6e4 in
> > > RTT::scripting::CommandDataSourceBool::readArguments() ()
> > >
> > > from
> > >
> > > /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/r
> > > tt/install/lib/orocos/plugins/librtt-scripting-gnulinux.so.2.2.0
> > > #17 0xb76552be in RTT::scripting::VertexNode::startExecution
> > > (this=0x80f686c)
> > >
> > > at
> > >
> > > /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/r
> > > tt/rtt/scripting/VertexNode.cpp:109 #18 0xb76bddfc in
> > > RTT::scripting::FunctionGraph::executeUntil (this=0x80f6800)
> > >
> > > at
> > >
> > > /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/r
> > > tt/rtt/scripting/FunctionGraph.cpp:248 #19 0xb76bdf90 in
> > > RTT::scripting::FunctionGraph::execute (this=0xb6fa0850)
> > >
> > > at
> > >
> > > /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/r
> > > tt/rtt/scripting/FunctionGraph.cpp:208 #20 0xb7716904 in
> > > RTT::scripting::ScriptParser::seenstatement (this=0xbfffe2a8)
> > >
> > > at
> > >
> > > /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/r
> > > tt/rtt/scripting/ScriptParser.cpp:83 #21 0xb771a4c5 in
> >
> > boost::spirit::classic::parser_result<boost::spirit::classic::kleene_
> > star<boost::spirit::classic::alternative > > rnative<boost::spirit::classic::alternative > > lternative<boost::spirit::classic::action > > e<boost::spirit::classic::scanner > > erator<__gnu_cxx::__normal_iterator<char*,
> >
> > > std::basic_string<char, std::char_traits > > > std::allocator<char> >
> > >
> > > > , boost::spirit::classic::file_positio---Type <return> to
> > > > continue, or
> > >
> > > q <return> to quit---
> >
> > Peter
> > --
> > Orocos-Users mailing list
> > Orocos-Users [..] ...
> > <mailto:Orocos-Users [..] ...>
> > http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
> >
> > Isn't it dangerous to play with Attributes between 2 Components ?
> > Shouldn't it be a port connection for thread safety ?

Peter

SOLVED

On 03/01/2011 10:05 AM, Dominick Vanthienen wrote:
>
>
>
>
> On 02/28/2011 08:41 PM, Willy Lambert wrote:
>>
>>
>> 2011/2/28 Peter Soetens<peter [..] ...peter [..] ...>>
>>
>> On Mon, Feb 28, 2011 at 6:48 PM, Dominick Vanthienen
>> <dominick [dot] vanthienen [..] ...dominick [dot] vanthienen [..] ...>> wrote:
>> >
>> >
>> > Dear all,
>> > I've a component that has to set some the value of some attributes of another component.
>> > The attributes of this 2nd component are created in the configure hook (once we know how many ther are to be created).
>> > When calling the attribute and asking whether he's ready: no problems, everything fine
>> > BUT when trying to get or set the value (in any order) it gives a segmentation fault.
>> >
>> > Similar code works fine, only difference: attributes are defined in the normal way: at construction time not in the configureHook
>> > There are multiple examples where ports are created in the configureHook.
>> >
>> > Is it not possible to create attributes/properties in the configureHook???
>>
>> It is, but your server-side code is wrong. It takes a reference to
>> your attribute object. If that lives
>> on the stack of your configureHook(), any code that tries to access it
>> will crash, as your bt shows.
>>
>> Write in configureHook() : provides()->setValue( new Attribute<double>( x ) );
>>
> This was not the problem, it is the following:
>
> MY COMPONENT THAT HAS THE ATTRIBUTE I WANT TO SET:
> //(in the HPP)
> std::vector<Priority*> priorities;
> struct Priority
> {
> public:
> unsigned int nc_priority;
> RTT::InputPort<Eigen::MatrixXd> A_port;
> }
>
> //(in the CPP)
> bool WDLSPriorVelSolver::configureHook()
> {
> priorities.resize(priorityNo) ;
> for (unsigned int i=0;i<priorityNo;i++)
> {

Stupid me, priorities is still a vector full of null pointers...

> //create attributes
> ssName.clear();
> ssName<< "nc_"<< i+1;
> ssName>> externalName;
> this->provides()->addAttribute(externalName,priorities[i]->nc_priority); => by changing priorities[i]->nc_priority to a normal variable, it works!!!
> //this->provides()->setValue( new Attribute<unsigned int>(externalName,priorities[i]->nc_priority) ); => this doesn't work either
> }
> return true;
> }
>
> But in the iTaSC implementation, something similar works already, with the difference that there is a map of tasks in stead of a vector of priorities!
> (already in RTT1.10, see example at our public repos: http://svn.mech.kuleuven.be/repos/orocos/trunk/kul-ros-pkg/iTaSC/src/Sce... look for the task or robot struct)
> The same problem occurs with the A_port creation, which is created with:
>
> //create ports
> ssName.clear();
> ssName<< "A_"<< i+1;
> ssName>> externalName;
> this->ports()->addPort(externalName, priorities[i]->A_port).doc("blabla");
>
>>
>> >
>> > Can anyone point me out to the source of the problem and suggest a solution?
>> >
>> > Thanks a lot,
>> > Nick
>> >
>> > THE CODE
>> > Attribute<unsigned int> nc;
>> > log(Info)<< "nc ready?= "<< nc.ready()<< endlog(); => returns 0 as expected
>> > for (unsigned int i=0;i<priorities.size();i++)
>> > {
>> > log(Info)<< "loop i = "<< i<< endlog();
>> > //set the attributes
>> > ssName.clear();
>> > ssName<< "nc_"<< i+1;
>> > ssName>> externalName;
>> > nc = peer->provides()->getAttribute(externalName);
>> > log(Info)<< "nc_i = "<< externalName<< endlog();
>> > if(!nc.ready())
>> > {
>> > log(Error)<< "Attribute nc_"<< i+1<< " of the Solver is not ready."<< endlog();
>> > return false;
>> > }
>> > log(Info)<< "nc ready?= "<< nc.ready()<< endlog(); => says it's ready
>> > log(Info)<< "nc value to set= "<< priorities[i]->nc_priority<< endlog(); => 6 in this case, which is an unsigned int
>> > log(Info)<< "nc value (get)="<<nc.get()< >> > nc.set(priorities[i]->nc_priority); => SEGFAULT
>> > log(Info)<< "nc set"<< endlog();
>> > }
>> >
>> > a BT of the segcault:
>> >
>> > 6.185 [ Info ][Scene] nc ready?= 0
>> > 6.185 [ Info ][Scene] loop i = 0
>> > 6.185 [ Info ][Scene] nc_i = nc_1
>> > 6.185 [ Info ][Scene] nc ready?= 1
>> > 6.185 [ Info ][Scene] nc value to set= 6
>> >
>> > Program received signal SIGSEGV, Segmentation fault.
>> > 0xb6fa085a in RTT::internal::ReferenceDataSource<unsigned int>::get
>> > (this=0xbfffd87c)
>> > at
>> > /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/rtt/rtt/typekit/../types/../internal/DataSources.hpp:225
>> > 225 typename DataSource<T>::result_t get() const
>> > (gdb) bt
>> > #0 0xb6fa085a in RTT::internal::ReferenceDataSource<unsigned int>::get
>> > (this=0xbfffd87c)
>> > at
>> > /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/rtt/rtt/typekit/../types/../internal/DataSources.hpp:225
>> > #1 0xb2c990d1 in iTaSC::ScenePriorities::addSolver (this=0x80ccdc0,
>> > PeerName=...)
>> > at
>> > /home/u0065688/src/svn/robotics-ros/packages/private-kul-ros-pkg/iTaSC/src/ScenePriorities.cpp:533
>> > #2 0xb2c968cc in iTaSC::ScenePriorities::configureHook (this=0x80ccdc0)
>> > at
>> > /home/u0065688/src/svn/robotics-ros/packages/private-kul-ros-pkg/iTaSC/src/ScenePriorities.cpp:243
>> > #3 0xb7eef0d7 in RTT::base::TaskCore::configure (this=0x80ccdc0) at
>> > /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/rtt/rtt/base/TaskCore.cpp:107
>> > #4 0xb7e856ea in call<RTT::TaskContext*> (function_obj_ptr=...) at
>> > /usr/include/boost/bind/mem_fn_template.hpp:40
>> > #5 operator()<RTT::TaskContext*> (function_obj_ptr=...) at
>> > /usr/include/boost/bind/mem_fn_template.hpp:55
>> > #6 operator()<bool, boost::_mfi::mf0 >> > boost::_bi::list0> (function_obj_ptr=...) at
>> > /usr/include/boost/bind/bind.hpp:243
>> > #7 operator() (function_obj_ptr=...) at
>> > /usr/include/boost/bind/bind_template.hpp:20
>> > #8
>> > boost::detail::function::function_obj_invoker0<boost::_bi::bind_t >> > boost::_mfi::mf0<bool, RTT::base::TaskCore>,
>> > boost::_bi::list1<boost::_bi::value >> > bool>::invoke (function_obj_ptr=...) at
>> > /usr/include/boost/function/function_template.hpp:132
>> > #9 0xb7e9dbac in RTT::internal::InvokerImpl<0, bool ()(),
>> > RTT::internal::LocalOperationCallerImpl<bool ()()> >::call() ()
>> > from
>> > /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/rtt/install/lib/liborocos-rtt-gnulinux.so.2.2
>> > #10 0xb7e87413 in call<bool
>> > (RTT::base::OperationCallerBase<bool()>::*)()> (f=&virtual table offset
>> > 12, s=...)
>> > at /usr/include/boost/fusion/functional/invocation/invoke.hpp:279
>> > #11 boost::fusion::invoke<bool
>> > (RTT::base::OperationCallerBase<bool()>::*)(),
>> > boost::fusion::cons<RTT::base::OperationCallerBase >> > boost::fusion::vector<boost::fusion::void_, boost::fusion::void_,
>> > boost::fusion::void_, boost::fusion::void_, boost::fusion::void_,
>> > boost::fusion::void_, boost::fusion::void_, boost::fusion::void_,
>> > boost::fusion::void_, boost::fusion::void_> > >(bool
>> > (RTT::base::OperationCallerBase<bool()>::*)(RTT::base::OperationCallerBase<bool()>
>> > *), const boost::fusion::cons<RTT::base::OperationCallerBase >> > boost::fusion::vector<boost::fusion::void_, boost::fusion::void_,
>> > boost::fusion::void_, boost::fusion::void_, boost::fusion::void_,
>> > boost::fusion::void_, boost::fusion::void_, boost::fusion::void_,
>> > boost::fusion::void_, boost::fusion::void_> > &) (f=&virtual table
>> > offset 12, s=...)
>> > at /usr/include/boost/fusion/functional/invocation/invoke.hpp:178
>> > #12 0xb7e86fb0 in operator()<bool,
>> > RTT::internal::FusedMCallDataSource::evaluate::iret (*)(bool
>> > (RTT::base::OperationCallerBase<bool()>::*)(), const
>> > RTT::internal::FusedMCallDataSource<Signature>::evaluate() const [with
>> > Signature = bool()]::arg_type&), boost::_bi::list0> (this=0x80f5f38) at
>> > /usr/include/boost/bind/bind.hpp:303
>> > #13 operator() (this=0x80f5f38) at
>> > /usr/include/boost/bind/bind_template.hpp:20
>> > #14 exec<boost::_bi::bind_t >> > RTT::internal::FusedMCallDataSource::evaluate::iret (*)(bool
>> > (RTT::base::OperationCallerBase<bool()>::*)(), const
>> > RTT::internal::FusedMCallDataSource<Signature>::evaluate() const [with
>> > Signature = bool()]::arg_type&),
>> > boost::_bi::list2<boost::_bi::value >> > (RTT::internal::InvokerBaseImpl<0, bool()>::*)()>,
>> > boost::_bi::value<boost::fusion::cons >> > boost::fusion::vector<boost::fusion::void_, boost::fusion::void_,
>> > boost::fusion::void_, boost::fusion::void_, boost::fusion::void_,
>> > boost::fusion::void_, boost::fusion::void_, boost::fusion::void_,
>> > boost::fusion::void_, boost::fusion::void_> > > > > > (
>> > this=0x80f5f38) at
>> > /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/rtt/rtt/internal/BindStorage.hpp:121
>> > #15 RTT::internal::FusedMCallDataSource<bool()>::evaluate(void) const
>> > (this=0x80f5f38)
>> > at
>> > /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/rtt/rtt/internal/FusedFunctorDataSource.hpp:298
>> > #16 0xb76db6e4 in RTT::scripting::CommandDataSourceBool::readArguments() ()
>> > from
>> > /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/rtt/install/lib/orocos/plugins/librtt-scripting-gnulinux.so.2.2.0
>> > #17 0xb76552be in RTT::scripting::VertexNode::startExecution
>> > (this=0x80f686c)
>> > at
>> > /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/rtt/rtt/scripting/VertexNode.cpp:109
>> > #18 0xb76bddfc in RTT::scripting::FunctionGraph::executeUntil
>> > (this=0x80f6800)
>> > at
>> > /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/rtt/rtt/scripting/FunctionGraph.cpp:248
>> > #19 0xb76bdf90 in RTT::scripting::FunctionGraph::execute (this=0xb6fa0850)
>> > at
>> > /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/rtt/rtt/scripting/FunctionGraph.cpp:208
>> > #20 0xb7716904 in RTT::scripting::ScriptParser::seenstatement
>> > (this=0xbfffe2a8)
>> > at
>> > /home/u0065688/src/svn/robotics-ros/packages/orocos_toolchain_ros/rtt/rtt/scripting/ScriptParser.cpp:83
>> > #21 0xb771a4c5 in
>> >
>> boost::spirit::classic::parser_result<boost::spirit::classic::kleene_star >> > std::basic_string<char, std::char_traits >> > > , boost::spirit::classic::file_positio---Type<return> to continue,
>> > > or
>> > q<return> to quit---
>> >
>>
>> Peter
>> --
>> Orocos-Users mailing list
>> Orocos-Users [..] ...<mailto:Orocos-Users [..] ...>
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>
>>
>>
>> Isn't it dangerous to play with Attributes between 2 Components ? Shouldn't it be a port connection for thread safety ?
>>
>>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users