[openrtm-users 01182] Re: Clean-up of OpenRTM application

[Michael Jäntsch]

Hi,

The proposed solution works fine for the cleanup of all our components now.
I still have a problem with the cleanup of the RTC::Manager, though. It 
seems that a bunch of threads are started when the runManager method is 
called but they are not terminated properly when the Manager is 
terminated. I still have two threads running after calling 
manager->terminate(), with the following backtrace:

#0  0x0012d422 in __kernel_vsyscall ()
#1  0x00a3b142 in pthread_cond_timedwait@@GLIBC_2.3.2 () from 
/lib/tls/i686/cmov/libpthread.so.0
#2  0x009c58d4 in pthread_cond_timedwait () from 
/lib/tls/i686/cmov/libc.so.6
#3  0x00bd3e48 in omni_condition::timedwait(unsigned long, unsigned 
long) () from /usr/lib/libomnithread.so.3
#4  0x00b35f79 in omni::Scavenger::execute (this=0x808aff8) at 
../../../../../src/lib/omniORB/orbcore/giopStrand.cc:719
#5  0x00ae5ca2 in omniAsyncWorker::real_run (this=0x808f0c8) at 
../../../../../src/lib/omniORB/orbcore/invoker.cc:232
#6  0x00ae565b in omniAsyncWorkerInfo::run (this=0xb6fd7314) at 
../../../../../src/lib/omniORB/orbcore/invoker.cc:280
#7  0x00ae5f5a in omniAsyncWorker::run (this=0x808f0c8) at 
../../../../../src/lib/omniORB/orbcore/invoker.cc:159
#8  0x00bd39c7 in omni_thread_wrapper () from /usr/lib/libomnithread.so.3
#9  0x00a3680e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#10 0x009b88de in clone () from /lib/tls/i686/cmov/libc.so.6

The method manager->join() is supposed to wait for the removal fo all 
threads and surely enough it does. One more thread gets closed but it 
stays in the join method indefinitely as the last missing worker thread 
is not exited. Am I missing something?

I am trying to restart the manager again after everything is closed in 
the same application. Is that possible at all? At the moment it gives me 
an error when I do that but I figure that it is due to the unclean state 
after manager->terminate().

thanks a lot
Michael Jäntsch



Am 11.03.2010 18:42, schrieb Steffen Wittmeier:
> Hello,
>
> this patch fixed a segmentation fault that I had when shutting down 
> the application. It did not, however, help with the omniorb error 
> message. I already figured out that the "omni_thread_fatal" message 
> only appears when the manager is run in non-blocking mode.
>
> Do I need to do anything else on clean-up? I found this on the web: 
> http://www.omniorb-support.com/pipermail/omniorb-list/2005-June/026811.html 
>
>
> Thanks,
> Steffen Wittmeier
>
> On 03/10/2010 06:14 AM, kurihara shinji wrote:
>> Hello,
>>
>> Please try to apply the patch attached to the mailing list 
>> "[openrtm-users 01149]".
>>   or
>> Please check out the source of the latest version from the following 
>> repositories.
>>
>>   
>> http://openrtp.jp/openrtm/svn/OpenRTM-aist/branches/RELENG_1_0/OpenRTM-aist 
>>
>>
>>
>> Regards,
>> Shinji Kurihara
>>
>> On Mon, 08 Mar 2010 18:04:32 +0100
>> Steffen Wittmeier<steffen.wittmeier ＠ in.tum.de>  wrote:
>>
>>> Hi,
>>>
>>> I am building a robot simulator application based on OpenRTM components
>>> (so that the simulator can smoothly be integrated with the real robot
>>> which also uses RTCs).
>>>
>>> The simulator GUI is using Qt and the main window as well as the
>>> individual widgets are derived from QMainWindow and QWidget,
>>> respectively, as well as from RTC::DataFlowComponentBase. Hence, every
>>> widget is a RTC and a GUI widget at the same time.
>>>
>>> This approach works quite well and I can even delete individual
>>> widgets/RTC at run-time by catching the widget close event and calling
>>> exit() on the component.
>>>
>>> However, I am having troubles with cleaning-up the application on
>>> closing. I am always getting the following error:
>>>
>>> terminate called after throwing an instance of 'omni_thread_fatal'
>>> Aborted
>>>
>>> What would be the right way of destructing the RTCs? I already updated
>>> to OpenRTM 1.0 as the destructors were not called when I used 
>>> OpenRTM 0.42.
>>>
>>> Any help is appreciated...
>>>
>>>
>>> Here's a snapshot of the code that I am using:
>>> int
>>> main(int argc, char** argv)
>>> {
>>>     RTC::Manager* manager;
>>>     manager = RTC::Manager::init(argc, argv);
>>>
>>>     // Initialize manager
>>>     manager->init(argc, argv);
>>>
>>>     // Set module initialization procedure
>>>     // that's where I create the basic components of the GUI
>>>     // (MainWindow, Model, Controller, LogManager)
>>>     manager->setModuleInitProc(createComponents);
>>>
>>>     // Activate manager and register to naming service
>>>     manager->activateManager();
>>>
>>>     // run the manager in non-blocking mode
>>>     manager->runManager(true);
>>>
>>>     // Qt main loop
>>>     application.exec();
>>>
>>>    // when the main loop exits, clean up components
>>>    // compMainWindow, compEcceosController, etc. are handles
>>>    // to the component, they are of type RTC::RtcBase*
>>>     if (compMainWindow != 0)
>>>     {
>>>       std::cout<<  "Exiting main window"<<  std::endl;
>>>       compMainWindow->exit();
>>>     }
>>>
>>>     if (compEcceosController != 0)
>>>     {
>>>       std::cout<<  "Exiting controller"<<  std::endl;
>>>       compEcceosController->exit();
>>>     }
>>>
>>>     if (compEcceosModel != 0)
>>>     {
>>>       std::cout<<  "Exiting model"<<  std::endl;
>>>       compEcceosModel->exit();
>>>     }
>>>
>>>     if (compLogManager != 0)
>>>     {
>>>       std::cout<<  "Exiting log manager"<<  std::endl;
>>>       //compLogManager->exit();
>>>     }
>>>
>>>     manager->terminate();
>>>
>>>     return 0;
>>> }
>>>
>>
>>
>


-- 
Technische Universität München
Michael Jäntsch
Fakultät für Informatik
Robotics and Embedded Systems
Boltzmannstr. 3
85748 Garching bei München
Tel: + 49.89.289.18100
Fax: + 49.89.289.18107
michael.jaentsch ＠ in.tum.de
www6.in.tum.de