RTT 1.10.3 and OCL 1.10.2 bug-fix releases

Both RTT and OCL feature new bug fix releases which accumulate the fixes for the bugs reported the last months. Users tracking the svn 1.10 branches will find nothing new in these releases.

For OCL, the fixes include:

  • Fixing Ctrl-D at the TaskBrowser prompt
  • Fixes in the DeploymentComponent for saving properties and setting activities.
  • Fix endless loop when unloading of a component fails.

And for RTT, the fixes include:

  • Remote Commands over CORBA did not evaluate their arguments.
  • Fix bug #737: Autosave adds unnecessary element when writing arrays.
  • Plenty of cmake fixes wrt Omniorb/TAO detection logic.
  • Fix bug #759: ControlTaskServer::CleanupServer causing segfault.
  • Improve compatibility with recent Xenomai releases.
  • Fix bug in ListLockFree where initial size was ignored.

See http://www.orocos.org/rtt/source and http://www.orocos.org/ocl/source for the downloads.

Peter

[Orocos] RTT 1.10.3 and OCL 1.10.2 bug-fix releases

On Apr 7, 2010, at 13:15 , Peter Soetens wrote:

> Both RTT and OCL feature new bug fix releases which accumulate the
> fixes for the bugs reported the last months. Users tracking the svn
> 1.10 branches will find nothing new in these releases.
>
> For OCL, the fixes include:
> * Fixing Ctrl-D at the TaskBrowser prompt
> * Fixes in the DeploymentComponent for saving properties and setting activities.
> * Fix endless loop when unloading of a component fails.
>
> And for RTT, the fixes include:
> * Remote Commands over CORBA did not evaluate their arguments.
> * Fix bug #737: Autosave adds unnecessary element when writing arrays.
> * Plenty of cmake fixes wrt Omniorb/TAO detection logic.
> * Fix bug #759: ControlTaskServer::CleanupServer causing segfault.

I still believe that the original cause of this bug remains. I still have problems quitting cleanly, e.g.


2.242 [ Debug  ][Deployer]  done
2.242 [ Debug  ][~ExecutionEngine] Destroying ExecutionEngine of Deployer
2.242 [ Info   ][ShutdownOrb] Cleaning up ControlTaskServers...
pure virtual method called
terminate called without an active exception

Program received signal SIGABRT, Aborted.
0x00007fff85aeafe6 in __kill ()
(gdb) bt
#0  0x00007fff85aeafe6 in __kill ()
#1  0x00007fff85b8be32 in abort ()
#2  0x00007fff86c585d2 in __gnu_cxx::__verbose_terminate_handler ()
#3  0x00007fff86c56ae1 in __cxxabiv1::__terminate ()
#4  0x00007fff86c56b16 in std::terminate ()
#5  0x00007fff86c56fd6 in __cxa_pure_virtual ()
#6  0x000000010167251d in RTT::Corba::ControlTaskServer::~ControlTaskServer ()
#7  0x0000000101672993 in RTT::Corba::ControlTaskServer::CleanupServers ()
#8  0x0000000101672cd1 in RTT::Corba::ControlTaskServer::DoShutdownOrb ()
#9  0x0000000101672ea7 in RTT::Corba::ControlTaskServer::ShutdownOrb ()
#10 0x0000000100007fe9 in main ()
(gdb) 


[Orocos] RTT 1.10.3 and OCL 1.10.2 bug-fix releases

On Wed, Apr 7, 2010 at 9:07 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
> On Apr 7, 2010, at 13:15 , Peter Soetens wrote:
>
>> Both RTT and OCL feature new bug fix releases which accumulate the
>> fixes for the bugs reported the last months. Users tracking the svn
>> 1.10 branches will find nothing new in these releases.
>>
>> For OCL, the fixes include:
>> * Fixing Ctrl-D at the TaskBrowser prompt
>> * Fixes in the DeploymentComponent for saving properties and setting activities.
>> * Fix endless loop when unloading of a component fails.
>>
>> And for RTT, the fixes include:
>> * Remote Commands over CORBA did not evaluate their arguments.
>> * Fix bug #737: Autosave adds unnecessary element when writing arrays.
>> * Plenty of cmake fixes wrt Omniorb/TAO detection logic.
>> * Fix bug #759: ControlTaskServer::CleanupServer causing segfault.
>
> I still believe that the original cause of this bug remains. I still have problems quitting cleanly, e.g.
>
> &#10;&gt; 2.242 [ Debug  ][Deployer]  done&#10;&gt; 2.242 [ Debug  ][~ExecutionEngine] Destroying ExecutionEngine of Deployer&#10;&gt; 2.242 [ Info   ][ShutdownOrb] Cleaning up ControlTaskServers...&#10;&gt; pure virtual method called&#10;&gt; terminate called without an active exception&#10;&gt;&#10;&gt; Program received signal SIGABRT, Aborted.&#10;&gt; 0x00007fff85aeafe6 in __kill ()&#10;&gt; (gdb) bt&#10;&gt; #0  0x00007fff85aeafe6 in __kill ()&#10;&gt; #1  0x00007fff85b8be32 in abort ()&#10;&gt; #2  0x00007fff86c585d2 in __gnu_cxx::__verbose_terminate_handler ()&#10;&gt; #3  0x00007fff86c56ae1 in __cxxabiv1::__terminate ()&#10;&gt; #4  0x00007fff86c56b16 in std::terminate ()&#10;&gt; #5  0x00007fff86c56fd6 in __cxa_pure_virtual ()&#10;&gt; #6  0x000000010167251d in RTT::Corba::ControlTaskServer::~ControlTaskServer ()&#10;&gt; #7  0x0000000101672993 in RTT::Corba::ControlTaskServer::CleanupServers ()&#10;&gt; #8  0x0000000101672cd1 in RTT::Corba::ControlTaskServer::DoShutdownOrb ()&#10;&gt; #9  0x0000000101672ea7 in RTT::Corba::ControlTaskServer::ShutdownOrb ()&#10;&gt; #10 0x0000000100007fe9 in main ()&#10;&gt; (gdb)&#10;&#10;Darn, this looks indeed familiar :-( Could you post the output of&#10;valgrind for reference ?&#10;&#10;I&#039;ll take a look at it next week.&#10;&#10;Peter

[Orocos] RTT 1.10.3 and OCL 1.10.2 bug-fix releases

On Apr 7, 2010, at 15:53 , Peter Soetens wrote:

> On Wed, Apr 7, 2010 at 9:07 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
>> On Apr 7, 2010, at 13:15 , Peter Soetens wrote:
>>
>>> Both RTT and OCL feature new bug fix releases which accumulate the
>>> fixes for the bugs reported the last months. Users tracking the svn
>>> 1.10 branches will find nothing new in these releases.
>>>
>>> For OCL, the fixes include:
>>> * Fixing Ctrl-D at the TaskBrowser prompt
>>> * Fixes in the DeploymentComponent for saving properties and setting activities.
>>> * Fix endless loop when unloading of a component fails.
>>>
>>> And for RTT, the fixes include:
>>> * Remote Commands over CORBA did not evaluate their arguments.
>>> * Fix bug #737: Autosave adds unnecessary element when writing arrays.
>>> * Plenty of cmake fixes wrt Omniorb/TAO detection logic.
>>> * Fix bug #759: ControlTaskServer::CleanupServer causing segfault.
>>
>> I still believe that the original cause of this bug remains. I still have problems quitting cleanly, e.g.
>>
>> &#10;&gt;&gt; 2.242 [ Debug  ][Deployer]  done&#10;&gt;&gt; 2.242 [ Debug  ][~ExecutionEngine] Destroying ExecutionEngine of Deployer&#10;&gt;&gt; 2.242 [ Info   ][ShutdownOrb] Cleaning up ControlTaskServers...&#10;&gt;&gt; pure virtual method called&#10;&gt;&gt; terminate called without an active exception&#10;&gt;&gt; &#10;&gt;&gt; Program received signal SIGABRT, Aborted.&#10;&gt;&gt; 0x00007fff85aeafe6 in __kill ()&#10;&gt;&gt; (gdb) bt&#10;&gt;&gt; #0  0x00007fff85aeafe6 in __kill ()&#10;&gt;&gt; #1  0x00007fff85b8be32 in abort ()&#10;&gt;&gt; #2  0x00007fff86c585d2 in __gnu_cxx::__verbose_terminate_handler ()&#10;&gt;&gt; #3  0x00007fff86c56ae1 in __cxxabiv1::__terminate ()&#10;&gt;&gt; #4  0x00007fff86c56b16 in std::terminate ()&#10;&gt;&gt; #5  0x00007fff86c56fd6 in __cxa_pure_virtual ()&#10;&gt;&gt; #6  0x000000010167251d in RTT::Corba::ControlTaskServer::~ControlTaskServer ()&#10;&gt;&gt; #7  0x0000000101672993 in RTT::Corba::ControlTaskServer::CleanupServers ()&#10;&gt;&gt; #8  0x0000000101672cd1 in RTT::Corba::ControlTaskServer::DoShutdownOrb ()&#10;&gt;&gt; #9  0x0000000101672ea7 in RTT::Corba::ControlTaskServer::ShutdownOrb ()&#10;&gt;&gt; #10 0x0000000100007fe9 in main ()&#10;&gt;&gt; (gdb)&#10;&gt; &#10;&gt; Darn, this looks indeed familiar :-( Could you post the output of&#10;&gt; valgrind for reference ?&#10;&gt; &#10;&gt; I&#039;ll take a look at it next week.&#10;&gt; &#10;&gt; Peter&#10;&#10;I think that I&#039;ve found it.&#10;&#10;There is an _implicit_ assumption within RTT::ControlTaskServer that ControlTasks are deleted _after_ their associated ControlTaskServer (as the ControlTaskServer dtor uses &quot;mtaskcontext-&gt;getName()&quot; ). What this means, is that you can not destroy an OCL::CorbaDeploymentComponent (which destroys all ControlTasks) before running ControlTaskServer::DestroyOrb (as that will finally delete all control task servers). &#10;&#10;Peter, you and I both violated this without realising it I think. You in 52386e8eef3ca58d1b03fa7992ce1452c3abaa00, and me in a private patch related to the rtlogging branch.&#10;&#10;The following patch won&#039;t apply clean I think, but it gets across what is required to fix this nasty little issue.&#10;&#10;I think, however, that the underlying design is bad. This could easily crop up again. There is a one-way assocation from ControlTaskServer to ControlTask. Anyone deleting a ControlTask _must_  explicitly deal with any associated ControlTaskServer, or this bug will occur again. It appears to me that ControlTaskServer is only using the name from ControlTask. If this is true, why not just store the name and be done with it? Is it this simple?&#10;&#10;Cheers&#10;Stephen&#10;

[Orocos] RTT 1.10.3 and OCL 1.10.2 bug-fix releases

On Wed, Apr 28, 2010 at 16:31, S Roderick <kiwi [dot] net [..] ...> wrote:

> On Apr 7, 2010, at 15:53 , Peter Soetens wrote:
>
> > On Wed, Apr 7, 2010 at 9:07 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
> >> On Apr 7, 2010, at 13:15 , Peter Soetens wrote:
> >>
> >>> Both RTT and OCL feature new bug fix releases which accumulate the
> >>> fixes for the bugs reported the last months. Users tracking the svn
> >>> 1.10 branches will find nothing new in these releases.
> >>>
> >>> For OCL, the fixes include:
> >>> * Fixing Ctrl-D at the TaskBrowser prompt
> >>> * Fixes in the DeploymentComponent for saving properties and setting
> activities.
> >>> * Fix endless loop when unloading of a component fails.
> >>>
> >>> And for RTT, the fixes include:
> >>> * Remote Commands over CORBA did not evaluate their arguments.
> >>> * Fix bug #737: Autosave adds unnecessary element when writing arrays.
> >>> * Plenty of cmake fixes wrt Omniorb/TAO detection logic.
> >>> * Fix bug #759: ControlTaskServer::CleanupServer causing segfault.
> >>
> >> I still believe that the original cause of this bug remains. I still
> have problems quitting cleanly, e.g.
> >>
> >> &#10;&gt; &gt;&gt; 2.242 [ Debug  ][Deployer]  done&#10;&gt; &gt;&gt; 2.242 [ Debug  ][~ExecutionEngine] Destroying ExecutionEngine of&#10;&gt; Deployer&#10;&gt; &gt;&gt; 2.242 [ Info   ][ShutdownOrb] Cleaning up ControlTaskServers...&#10;&gt; &gt;&gt; pure virtual method called&#10;&gt; &gt;&gt; terminate called without an active exception&#10;&gt; &gt;&gt;&#10;&gt; &gt;&gt; Program received signal SIGABRT, Aborted.&#10;&gt; &gt;&gt; 0x00007fff85aeafe6 in __kill ()&#10;&gt; &gt;&gt; (gdb) bt&#10;&gt; &gt;&gt; #0  0x00007fff85aeafe6 in __kill ()&#10;&gt; &gt;&gt; #1  0x00007fff85b8be32 in abort ()&#10;&gt; &gt;&gt; #2  0x00007fff86c585d2 in __gnu_cxx::__verbose_terminate_handler ()&#10;&gt; &gt;&gt; #3  0x00007fff86c56ae1 in __cxxabiv1::__terminate ()&#10;&gt; &gt;&gt; #4  0x00007fff86c56b16 in std::terminate ()&#10;&gt; &gt;&gt; #5  0x00007fff86c56fd6 in __cxa_pure_virtual ()&#10;&gt; &gt;&gt; #6  0x000000010167251d in&#10;&gt; RTT::Corba::ControlTaskServer::~ControlTaskServer ()&#10;&gt; &gt;&gt; #7  0x0000000101672993 in RTT::Corba::ControlTaskServer::CleanupServers&#10;&gt; ()&#10;&gt; &gt;&gt; #8  0x0000000101672cd1 in RTT::Corba::ControlTaskServer::DoShutdownOrb&#10;&gt; ()&#10;&gt; &gt;&gt; #9  0x0000000101672ea7 in RTT::Corba::ControlTaskServer::ShutdownOrb ()&#10;&gt; &gt;&gt; #10 0x0000000100007fe9 in main ()&#10;&gt; &gt;&gt; (gdb)&#10;&gt; &gt;&#10;&gt; &gt; Darn, this looks indeed familiar :-( Could you post the output of&#10;&gt; &gt; valgrind for reference ?&#10;&gt; &gt;&#10;&gt; &gt; I&#039;ll take a look at it next week.&#10;&gt; &gt;&#10;&gt; &gt; Peter&#10;&gt;&#10;&gt; I think that I&#039;ve found it.&#10;&gt;&#10;&gt; There is an _implicit_ assumption within RTT::ControlTaskServer that&#10;&gt; ControlTasks are deleted _after_ their associated ControlTaskServer (as the&#10;&gt; ControlTaskServer dtor uses &quot;mtaskcontext-&gt;getName()&quot; ). What this means, is&#10;&gt; that you can not destroy an OCL::CorbaDeploymentComponent (which destroys&#10;&gt; all ControlTasks) before running ControlTaskServer::DestroyOrb (as that will&#10;&gt; finally delete all control task servers).&#10;&gt;&#10;&gt; Peter, you and I both violated this without realising it I think. You in&#10;&gt; 52386e8eef3ca58d1b03fa7992ce1452c3abaa00, and me in a private patch related&#10;&gt; to the rtlogging branch.&#10;&gt;&#10;&gt; The following patch won&#039;t apply clean I think, but it gets across what is&#10;&gt; required to fix this nasty little issue.&#10;&gt;&#10;&gt; I think, however, that the underlying design is bad. This could easily crop&#10;&gt; up again. There is a one-way assocation from ControlTaskServer to&#10;&gt; ControlTask. Anyone deleting a ControlTask _must_  explicitly deal with any&#10;&gt; associated ControlTaskServer, or this bug will occur again. It appears to me&#10;&gt; that ControlTaskServer is only using the name from ControlTask. If this is&#10;&gt; true, why not just store the name and be done with it? Is it this simple?&#10;&gt;&#10;&#10;The design is indeed bad. The problem is that the server process can crash&#10;from the moment the TaskContext is deleted. Since from that moment *both*&#10;ControlTaskServer and ControlTask_i point to invalid memory. So your&#10;proposal only fixes the first one. Any remote client call would cause the&#10;second to crash though. Your patch is really a &#039;causality hack&#039; btw :-).&#10;&#10;The solution is to have a system to inform interested parties that a&#10;TaskContext disappears /  is being deleted. I can only do this cleanly in&#10;2.x. In 1.x, we could insert a specially crafted TaskObject in the interface&#10;that calls us (ControlTaskServer) back when it&#039;s being cleaned up. That&#039;s a&#10;hack, but we could hide this TaskObject when exporting the interface to the&#10;CORBA layer. Call it something like &#039;corbaserver&#039;. Maybe I&#039;m overlooking&#10;something...&#10;&#10;Peter

[Orocos] RTT 1.10.3 and OCL 1.10.2 bug-fix releases

On Apr 28, 2010, at 11:36 , Peter Soetens wrote:

> On Wed, Apr 28, 2010 at 16:31, S Roderick <kiwi [dot] net [..] ...> wrote:
> On Apr 7, 2010, at 15:53 , Peter Soetens wrote:
>
> > On Wed, Apr 7, 2010 at 9:07 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
> >> On Apr 7, 2010, at 13:15 , Peter Soetens wrote:
> >>
> >>> Both RTT and OCL feature new bug fix releases which accumulate the
> >>> fixes for the bugs reported the last months. Users tracking the svn
> >>> 1.10 branches will find nothing new in these releases.
> >>>
> >>> For OCL, the fixes include:
> >>> * Fixing Ctrl-D at the TaskBrowser prompt
> >>> * Fixes in the DeploymentComponent for saving properties and setting activities.
> >>> * Fix endless loop when unloading of a component fails.
> >>>
> >>> And for RTT, the fixes include:
> >>> * Remote Commands over CORBA did not evaluate their arguments.
> >>> * Fix bug #737: Autosave adds unnecessary element when writing arrays.
> >>> * Plenty of cmake fixes wrt Omniorb/TAO detection logic.
> >>> * Fix bug #759: ControlTaskServer::CleanupServer causing segfault.
> >>
> >> I still believe that the original cause of this bug remains. I still have problems quitting cleanly, e.g.
> >>
> >> &#10;&gt; &gt;&gt; 2.242 [ Debug  ][Deployer]  done&#10;&gt; &gt;&gt; 2.242 [ Debug  ][~ExecutionEngine] Destroying ExecutionEngine of Deployer&#10;&gt; &gt;&gt; 2.242 [ Info   ][ShutdownOrb] Cleaning up ControlTaskServers...&#10;&gt; &gt;&gt; pure virtual method called&#10;&gt; &gt;&gt; terminate called without an active exception&#10;&gt; &gt;&gt;&#10;&gt; &gt;&gt; Program received signal SIGABRT, Aborted.&#10;&gt; &gt;&gt; 0x00007fff85aeafe6 in __kill ()&#10;&gt; &gt;&gt; (gdb) bt&#10;&gt; &gt;&gt; #0  0x00007fff85aeafe6 in __kill ()&#10;&gt; &gt;&gt; #1  0x00007fff85b8be32 in abort ()&#10;&gt; &gt;&gt; #2  0x00007fff86c585d2 in __gnu_cxx::__verbose_terminate_handler ()&#10;&gt; &gt;&gt; #3  0x00007fff86c56ae1 in __cxxabiv1::__terminate ()&#10;&gt; &gt;&gt; #4  0x00007fff86c56b16 in std::terminate ()&#10;&gt; &gt;&gt; #5  0x00007fff86c56fd6 in __cxa_pure_virtual ()&#10;&gt; &gt;&gt; #6  0x000000010167251d in RTT::Corba::ControlTaskServer::~ControlTaskServer ()&#10;&gt; &gt;&gt; #7  0x0000000101672993 in RTT::Corba::ControlTaskServer::CleanupServers ()&#10;&gt; &gt;&gt; #8  0x0000000101672cd1 in RTT::Corba::ControlTaskServer::DoShutdownOrb ()&#10;&gt; &gt;&gt; #9  0x0000000101672ea7 in RTT::Corba::ControlTaskServer::ShutdownOrb ()&#10;&gt; &gt;&gt; #10 0x0000000100007fe9 in main ()&#10;&gt; &gt;&gt; (gdb)&#10;&gt; &gt;&#10;&gt; &gt; Darn, this looks indeed familiar :-( Could you post the output of&#10;&gt; &gt; valgrind for reference ?&#10;&gt; &gt;&#10;&gt; &gt; I&#039;ll take a look at it next week.&#10;&gt; &gt;&#10;&gt; &gt; Peter&#10;&gt; &#10;&gt; I think that I&#039;ve found it.&#10;&gt; &#10;&gt; There is an _implicit_ assumption within RTT::ControlTaskServer that ControlTasks are deleted _after_ their associated ControlTaskServer (as the ControlTaskServer dtor uses &quot;mtaskcontext-&gt;getName()&quot; ). What this means, is that you can not destroy an OCL::CorbaDeploymentComponent (which destroys all ControlTasks) before running ControlTaskServer::DestroyOrb (as that will finally delete all control task servers).&#10;&gt; &#10;&gt; Peter, you and I both violated this without realising it I think. You in 52386e8eef3ca58d1b03fa7992ce1452c3abaa00, and me in a private patch related to the rtlogging branch.&#10;&gt; &#10;&gt; The following patch won&#039;t apply clean I think, but it gets across what is required to fix this nasty little issue.&#10;&gt; &#10;&gt; I think, however, that the underlying design is bad. This could easily crop up again. There is a one-way assocation from ControlTaskServer to ControlTask. Anyone deleting a ControlTask _must_  explicitly deal with any associated ControlTaskServer, or this bug will occur again. It appears to me that ControlTaskServer is only using the name from ControlTask. If this is true, why not just store the name and be done with it? Is it this simple?&#10;&gt; &#10;&gt; The design is indeed bad. The problem is that the server process can crash from the moment the TaskContext is deleted. Since from that moment *both* ControlTaskServer and ControlTask_i point to invalid memory. So your proposal only fixes the first one. Any remote client call would cause the second to crash though. Your patch is really a &#039;causality hack&#039; btw :-). &#10;&#10;Yes, it is a hack! Gets the job done for now though ...&#10;&#10;&gt; The solution is to have a system to inform interested parties that a TaskContext disappears /  is being deleted. I can only do this cleanly in 2.x. In 1.x, we could insert a specially crafted TaskObject in the interface that calls us (ControlTaskServer) back when it&#039;s being cleaned up. That&#039;s a hack, but we could hide this TaskObject when exporting the interface to the CORBA layer. Call it something like &#039;corbaserver&#039;. Maybe I&#039;m overlooking something...&#10;&#10;Yes, we need to manage the two-way association somehow. If you can fix this in v2 and then leave a nasty big warning with v1, maybe that is good enough for now? We&#039;d also need to ensure that the next v1 point release notes spelled out how and why the issue occurs, for those not using the deployers. Seems I&#039;m the only one to date that has encountered this ... or at least the only one that complains when I do ... :-)&#10;&#10;Can you fix this cleanly (and easily) in v2?&#10;S&#10;

[Orocos] RTT 1.10.3 and OCL 1.10.2 bug-fix releases

On Wednesday 28 April 2010 18:25:27 Stephen Roderick wrote:
> On Apr 28, 2010, at 11:36 , Peter Soetens wrote:
> > On Wed, Apr 28, 2010 at 16:31, S Roderick <kiwi [dot] net [..] ...> wrote:
> >
> > On Apr 7, 2010, at 15:53 , Peter Soetens wrote:
> > > On Wed, Apr 7, 2010 at 9:07 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
> > >> On Apr 7, 2010, at 13:15 , Peter Soetens wrote:
> > >>> Both RTT and OCL feature new bug fix releases which accumulate the
> > >>> fixes for the bugs reported the last months. Users tracking the svn
> > >>> 1.10 branches will find nothing new in these releases.
> > >>>
> > >>> For OCL, the fixes include:
> > >>> * Fixing Ctrl-D at the TaskBrowser prompt
> > >>> * Fixes in the DeploymentComponent for saving properties and setting
> > >>> activities. * Fix endless loop when unloading of a component fails.
> > >>>
> > >>> And for RTT, the fixes include:
> > >>> * Remote Commands over CORBA did not evaluate their arguments.
> > >>> * Fix bug #737: Autosave adds unnecessary element when writing
> > >>> arrays. * Plenty of cmake fixes wrt Omniorb/TAO detection logic.
> > >>> * Fix bug #759: ControlTaskServer::CleanupServer causing segfault.
> > >>
> > >> I still believe that the original cause of this bug remains. I still
> > >> have problems quitting cleanly, e.g.
> > >>
> > >> &#10;&gt; &gt; &gt;&gt; 2.242 [ Debug  ][Deployer]  done&#10;&gt; &gt; &gt;&gt; 2.242 [ Debug  ][~ExecutionEngine] Destroying ExecutionEngine of&#10;&gt; &gt; &gt;&gt; Deployer 2.242 [ Info   ][ShutdownOrb] Cleaning up&#10;&gt; &gt; &gt;&gt; ControlTaskServers... pure virtual method called&#10;&gt; &gt; &gt;&gt; terminate called without an active exception&#10;&gt; &gt; &gt;&gt;&#10;&gt; &gt; &gt;&gt; Program received signal SIGABRT, Aborted.&#10;&gt; &gt; &gt;&gt; 0x00007fff85aeafe6 in __kill ()&#10;&gt; &gt; &gt;&gt; (gdb) bt&#10;&gt; &gt; &gt;&gt; #0  0x00007fff85aeafe6 in __kill ()&#10;&gt; &gt; &gt;&gt; #1  0x00007fff85b8be32 in abort ()&#10;&gt; &gt; &gt;&gt; #2  0x00007fff86c585d2 in __gnu_cxx::__verbose_terminate_handler ()&#10;&gt; &gt; &gt;&gt; #3  0x00007fff86c56ae1 in __cxxabiv1::__terminate ()&#10;&gt; &gt; &gt;&gt; #4  0x00007fff86c56b16 in std::terminate ()&#10;&gt; &gt; &gt;&gt; #5  0x00007fff86c56fd6 in __cxa_pure_virtual ()&#10;&gt; &gt; &gt;&gt; #6  0x000000010167251d in&#10;&gt; &gt; &gt;&gt; RTT::Corba::ControlTaskServer::~ControlTaskServer () #7 &#10;&gt; &gt; &gt;&gt; 0x0000000101672993 in RTT::Corba::ControlTaskServer::CleanupServers ()&#10;&gt; &gt; &gt;&gt; #8  0x0000000101672cd1 in RTT::Corba::ControlTaskServer::DoShutdownOrb&#10;&gt; &gt; &gt;&gt; () #9  0x0000000101672ea7 in&#10;&gt; &gt; &gt;&gt; RTT::Corba::ControlTaskServer::ShutdownOrb () #10 0x0000000100007fe9&#10;&gt; &gt; &gt;&gt; in main ()&#10;&gt; &gt; &gt;&gt; (gdb)&#10;&gt; &gt; &gt;&#10;&gt; &gt; &gt; Darn, this looks indeed familiar :-( Could you post the output of&#10;&gt; &gt; &gt; valgrind for reference ?&#10;&gt; &gt; &gt;&#10;&gt; &gt; &gt; I&#039;ll take a look at it next week.&#10;&gt; &gt; &gt;&#10;&gt; &gt; &gt; Peter&#10;&gt; &gt;&#10;&gt; &gt; I think that I&#039;ve found it.&#10;&gt; &gt;&#10;&gt; &gt; There is an _implicit_ assumption within RTT::ControlTaskServer that&#10;&gt; &gt; ControlTasks are deleted _after_ their associated ControlTaskServer (as&#10;&gt; &gt; the ControlTaskServer dtor uses &quot;mtaskcontext-&gt;getName()&quot; ). What this&#10;&gt; &gt; means, is that you can not destroy an OCL::CorbaDeploymentComponent&#10;&gt; &gt; (which destroys all ControlTasks) before running&#10;&gt; &gt; ControlTaskServer::DestroyOrb (as that will finally delete all control&#10;&gt; &gt; task servers).&#10;&gt; &gt;&#10;&gt; &gt; Peter, you and I both violated this without realising it I think. You in&#10;&gt; &gt; 52386e8eef3ca58d1b03fa7992ce1452c3abaa00, and me in a private patch&#10;&gt; &gt; related to the rtlogging branch.&#10;&gt; &gt;&#10;&gt; &gt; The following patch won&#039;t apply clean I think, but it gets across what is&#10;&gt; &gt; required to fix this nasty little issue.&#10;&gt; &gt;&#10;&gt; &gt; I think, however, that the underlying design is bad. This could easily&#10;&gt; &gt; crop up again. There is a one-way assocation from ControlTaskServer to&#10;&gt; &gt; ControlTask. Anyone deleting a ControlTask _must_  explicitly deal with&#10;&gt; &gt; any associated ControlTaskServer, or this bug will occur again. It&#10;&gt; &gt; appears to me that ControlTaskServer is only using the name from&#10;&gt; &gt; ControlTask. If this is true, why not just store the name and be done&#10;&gt; &gt; with it? Is it this simple?&#10;&gt; &gt;&#10;&gt; &gt; The design is indeed bad. The problem is that the server process can&#10;&gt; &gt; crash from the moment the TaskContext is deleted. Since from that moment&#10;&gt; &gt; *both* ControlTaskServer and ControlTask_i point to invalid memory. So&#10;&gt; &gt; your proposal only fixes the first one. Any remote client call would&#10;&gt; &gt; cause the second to crash though. Your patch is really a &#039;causality hack&#039;&#10;&gt; &gt; btw :-).&#10;&gt; &#10;&gt; Yes, it is a hack! Gets the job done for now though ...&#10;&gt; &#10;&gt; &gt; The solution is to have a system to inform interested parties that a&#10;&gt; &gt; TaskContext disappears /  is being deleted. I can only do this cleanly in&#10;&gt; &gt; 2.x. In 1.x, we could insert a specially crafted TaskObject in the&#10;&gt; &gt; interface that calls us (ControlTaskServer) back when it&#039;s being cleaned&#10;&gt; &gt; up. That&#039;s a hack, but we could hide this TaskObject when exporting the&#10;&gt; &gt; interface to the CORBA layer. Call it something like &#039;corbaserver&#039;. Maybe&#10;&gt; &gt; I&#039;m overlooking something...&#10;&gt; &#10;&gt; Yes, we need to manage the two-way association somehow. If you can fix this&#10;&gt;  in v2 and then leave a nasty big warning with v1, maybe that is good&#10;&gt;  enough for now? We&#039;d also need to ensure that the next v1 point release&#10;&gt;  notes spelled out how and why the issue occurs, for those not using the&#10;&gt;  deployers. Seems I&#039;m the only one to date that has encountered this ... or&#10;&gt;  at least the only one that complains when I do ... :-)&#10;&gt; &#10;&gt; Can you fix this cleanly (and easily) in v2?&#10;&#10;It&#039;s the &#039;service discovery&#039; feature of 2.2, where creation or destruction of &#10;components, their interfaces and connections are being announced to the &#10;process, or to the network. Allowing automatic reconnection when a component &#10;goes out and back in.&#10;&#10;See the bug report for the patch I had in mind. It&#039;s even binary compatible, &#10;but it adds the &#039;corbaservice&#039; to any component running with a CORBA server.&#10;&#10;I did not apply your patch, but I did apply some memory leak fixes for the &#10;CORBA code, which I don&#039;t think influence this bug.&#10;&#10;If this works for you, I&#039;ll push my fixes to svn &amp; github.&#10;&#10;Peter

[Orocos] RTT 1.10.3 and OCL 1.10.2 bug-fix releases

On Apr 29, 2010, at 09:43 , Peter Soetens wrote:

> On Wednesday 28 April 2010 18:25:27 Stephen Roderick wrote:
>> On Apr 28, 2010, at 11:36 , Peter Soetens wrote:
>>> On Wed, Apr 28, 2010 at 16:31, S Roderick <kiwi [dot] net [..] ...> wrote:
>>>
>>> On Apr 7, 2010, at 15:53 , Peter Soetens wrote:
>>>> On Wed, Apr 7, 2010 at 9:07 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
>>>>> On Apr 7, 2010, at 13:15 , Peter Soetens wrote:
>>>>>> Both RTT and OCL feature new bug fix releases which accumulate the
>>>>>> fixes for the bugs reported the last months. Users tracking the svn
>>>>>> 1.10 branches will find nothing new in these releases.
>>>>>>
>>>>>> For OCL, the fixes include:
>>>>>> * Fixing Ctrl-D at the TaskBrowser prompt
>>>>>> * Fixes in the DeploymentComponent for saving properties and setting
>>>>>> activities. * Fix endless loop when unloading of a component fails.
>>>>>>
>>>>>> And for RTT, the fixes include:
>>>>>> * Remote Commands over CORBA did not evaluate their arguments.
>>>>>> * Fix bug #737: Autosave adds unnecessary element when writing
>>>>>> arrays. * Plenty of cmake fixes wrt Omniorb/TAO detection logic.
>>>>>> * Fix bug #759: ControlTaskServer::CleanupServer causing segfault.
>>>>>
>>>>> I still believe that the original cause of this bug remains. I still
>>>>> have problems quitting cleanly, e.g.
>>>>>
>>>>> &#10;&gt;&gt;&gt;&gt;&gt; 2.242 [ Debug  ][Deployer]  done&#10;&gt;&gt;&gt;&gt;&gt; 2.242 [ Debug  ][~ExecutionEngine] Destroying ExecutionEngine of&#10;&gt;&gt;&gt;&gt;&gt; Deployer 2.242 [ Info   ][ShutdownOrb] Cleaning up&#10;&gt;&gt;&gt;&gt;&gt; ControlTaskServers... pure virtual method called&#10;&gt;&gt;&gt;&gt;&gt; terminate called without an active exception&#10;&gt;&gt;&gt;&gt;&gt; &#10;&gt;&gt;&gt;&gt;&gt; Program received signal SIGABRT, Aborted.&#10;&gt;&gt;&gt;&gt;&gt; 0x00007fff85aeafe6 in __kill ()&#10;&gt;&gt;&gt;&gt;&gt; (gdb) bt&#10;&gt;&gt;&gt;&gt;&gt; #0  0x00007fff85aeafe6 in __kill ()&#10;&gt;&gt;&gt;&gt;&gt; #1  0x00007fff85b8be32 in abort ()&#10;&gt;&gt;&gt;&gt;&gt; #2  0x00007fff86c585d2 in __gnu_cxx::__verbose_terminate_handler ()&#10;&gt;&gt;&gt;&gt;&gt; #3  0x00007fff86c56ae1 in __cxxabiv1::__terminate ()&#10;&gt;&gt;&gt;&gt;&gt; #4  0x00007fff86c56b16 in std::terminate ()&#10;&gt;&gt;&gt;&gt;&gt; #5  0x00007fff86c56fd6 in __cxa_pure_virtual ()&#10;&gt;&gt;&gt;&gt;&gt; #6  0x000000010167251d in&#10;&gt;&gt;&gt;&gt;&gt; RTT::Corba::ControlTaskServer::~ControlTaskServer () #7 &#10;&gt;&gt;&gt;&gt;&gt; 0x0000000101672993 in RTT::Corba::ControlTaskServer::CleanupServers ()&#10;&gt;&gt;&gt;&gt;&gt; #8  0x0000000101672cd1 in RTT::Corba::ControlTaskServer::DoShutdownOrb&#10;&gt;&gt;&gt;&gt;&gt; () #9  0x0000000101672ea7 in&#10;&gt;&gt;&gt;&gt;&gt; RTT::Corba::ControlTaskServer::ShutdownOrb () #10 0x0000000100007fe9&#10;&gt;&gt;&gt;&gt;&gt; in main ()&#10;&gt;&gt;&gt;&gt;&gt; (gdb)&#10;&gt;&gt;&gt;&gt; &#10;&gt;&gt;&gt;&gt; Darn, this looks indeed familiar :-( Could you post the output of&#10;&gt;&gt;&gt;&gt; valgrind for reference ?&#10;&gt;&gt;&gt;&gt; &#10;&gt;&gt;&gt;&gt; I&#039;ll take a look at it next week.&#10;&gt;&gt;&gt;&gt; &#10;&gt;&gt;&gt;&gt; Peter&#10;&gt;&gt;&gt; &#10;&gt;&gt;&gt; I think that I&#039;ve found it.&#10;&gt;&gt;&gt; &#10;&gt;&gt;&gt; There is an _implicit_ assumption within RTT::ControlTaskServer that&#10;&gt;&gt;&gt; ControlTasks are deleted _after_ their associated ControlTaskServer (as&#10;&gt;&gt;&gt; the ControlTaskServer dtor uses &quot;mtaskcontext-&gt;getName()&quot; ). What this&#10;&gt;&gt;&gt; means, is that you can not destroy an OCL::CorbaDeploymentComponent&#10;&gt;&gt;&gt; (which destroys all ControlTasks) before running&#10;&gt;&gt;&gt; ControlTaskServer::DestroyOrb (as that will finally delete all control&#10;&gt;&gt;&gt; task servers).&#10;&gt;&gt;&gt; &#10;&gt;&gt;&gt; Peter, you and I both violated this without realising it I think. You in&#10;&gt;&gt;&gt; 52386e8eef3ca58d1b03fa7992ce1452c3abaa00, and me in a private patch&#10;&gt;&gt;&gt; related to the rtlogging branch.&#10;&gt;&gt;&gt; &#10;&gt;&gt;&gt; The following patch won&#039;t apply clean I think, but it gets across what is&#10;&gt;&gt;&gt; required to fix this nasty little issue.&#10;&gt;&gt;&gt; &#10;&gt;&gt;&gt; I think, however, that the underlying design is bad. This could easily&#10;&gt;&gt;&gt; crop up again. There is a one-way assocation from ControlTaskServer to&#10;&gt;&gt;&gt; ControlTask. Anyone deleting a ControlTask _must_  explicitly deal with&#10;&gt;&gt;&gt; any associated ControlTaskServer, or this bug will occur again. It&#10;&gt;&gt;&gt; appears to me that ControlTaskServer is only using the name from&#10;&gt;&gt;&gt; ControlTask. If this is true, why not just store the name and be done&#10;&gt;&gt;&gt; with it? Is it this simple?&#10;&gt;&gt;&gt; &#10;&gt;&gt;&gt; The design is indeed bad. The problem is that the server process can&#10;&gt;&gt;&gt; crash from the moment the TaskContext is deleted. Since from that moment&#10;&gt;&gt;&gt; *both* ControlTaskServer and ControlTask_i point to invalid memory. So&#10;&gt;&gt;&gt; your proposal only fixes the first one. Any remote client call would&#10;&gt;&gt;&gt; cause the second to crash though. Your patch is really a &#039;causality hack&#039;&#10;&gt;&gt;&gt; btw :-).&#10;&gt;&gt; &#10;&gt;&gt; Yes, it is a hack! Gets the job done for now though ...&#10;&gt;&gt; &#10;&gt;&gt;&gt; The solution is to have a system to inform interested parties that a&#10;&gt;&gt;&gt; TaskContext disappears /  is being deleted. I can only do this cleanly in&#10;&gt;&gt;&gt; 2.x. In 1.x, we could insert a specially crafted TaskObject in the&#10;&gt;&gt;&gt; interface that calls us (ControlTaskServer) back when it&#039;s being cleaned&#10;&gt;&gt;&gt; up. That&#039;s a hack, but we could hide this TaskObject when exporting the&#10;&gt;&gt;&gt; interface to the CORBA layer. Call it something like &#039;corbaserver&#039;. Maybe&#10;&gt;&gt;&gt; I&#039;m overlooking something...&#10;&gt;&gt; &#10;&gt;&gt; Yes, we need to manage the two-way association somehow. If you can fix this&#10;&gt;&gt; in v2 and then leave a nasty big warning with v1, maybe that is good&#10;&gt;&gt; enough for now? We&#039;d also need to ensure that the next v1 point release&#10;&gt;&gt; notes spelled out how and why the issue occurs, for those not using the&#10;&gt;&gt; deployers. Seems I&#039;m the only one to date that has encountered this ... or&#10;&gt;&gt; at least the only one that complains when I do ... :-)&#10;&gt;&gt; &#10;&gt;&gt; Can you fix this cleanly (and easily) in v2?&#10;&gt; &#10;&gt; It&#039;s the &#039;service discovery&#039; feature of 2.2, where creation or destruction of &#10;&gt; components, their interfaces and connections are being announced to the &#10;&gt; process, or to the network. Allowing automatic reconnection when a component &#10;&gt; goes out and back in.&#10;&gt; &#10;&gt; See the bug report for the patch I had in mind. It&#039;s even binary compatible, &#10;&gt; but it adds the &#039;corbaservice&#039; to any component running with a CORBA server.&#10;&gt; &#10;&gt; I did not apply your patch, but I did apply some memory leak fixes for the &#10;&gt; CORBA code, which I don&#039;t think influence this bug.&#10;&gt; &#10;&gt; If this works for you, I&#039;ll push my fixes to svn &amp; github.&#10;&gt; &#10;&gt; Peter&#10;&#10;Probably will be early next week before I get a chance to look at this, but it sounds good. Thanks!!&#10;Stephen