[Ace-users] Re: [tao-users] mixing omniORB and TAO within one process

[Johnny Willemsen]

Hi,
 
Maybe start TAO with -ORBDebugLevel 10 and see what it gives for output.
 
Regards,
 
Johnny Willemsen
Remedy IT
Postbus 101
2650 AC  Berkel en Rodenrijs
The Netherlands
www.theaceorb.nl / www.remedy.nl 

*** Integrated compile and test statistics see
http://scoreboard.theaceorb.nl <http://scoreboard.theaceorb.nl/>  ***
*** Commercial service and support for ACE/TAO/CIAO             ***
*** See http://www.theaceorb.nl/en/support.html                 *** 


________________________________

	From: Friedhelm Wolf [mailto:friedhelm.wolf at googlemail.com] 
	Sent: Thursday, June 21, 2007 5:14 PM
	To: Johnny Willemsen
	Cc: tao-users at cse.wustl.edu
	Subject: Re: [tao-users] mixing omniORB and TAO within one process
	
	
	Johnny,
	
	after debugging into all that I found out, that you are right.
	Somehow the ORB_init() call doesn't work properly also the programm
	returns from the call correctly. When I then try to access the POA I
get a segfault. 
	
	I recognized omniORB is somehow "taking over" memory management,
because
	during execution of the TAO ORB_init() call, the following message
appears on stdout:
	
	omniORB: ERROR -- an invalid buffer pointer is passed to freebuf 
	 of string or object  sequence
	
	I found out, that this results from a global error handler function
(or something like that),
	void _CORBA_bad_param_freebuf() in omniORB/orbcore/exception.cc
	
	But maybe this is something I have to ask some omniORB guys. I'm not
very familiar with 
	omniORB. Can anyone point me to a developer forum for omniORB? Is
there an active
	developer community?
	
	Thanks,
	Friedhelm
	
	
	On 6/20/07, Johnny Willemsen <jwillemsen at remedy.nl> wrote: 

		Hi,
		 
		It looks to me that the TAO POA isn't created before you
activate the servant.
		 
		Johnny


________________________________

			From: tao-users-bounces at cse.wustl.edu
[mailto:tao-users-bounces at cse.wustl.edu] On Behalf Of Friedhelm Wolf
			Sent: Wednesday, June 20, 2007 5:11 PM
			To: tao-users at cse.wustl.edu
			Subject: [tao-users] mixing omniORB and TAO within
one process
			
			
						CIAO VERSION: 0.5.8
			TAO VERSION : 1.5.8
			ACE VERSION : 5.5.8
			
			HOST MACHINE and OPERATING SYSTEM:
			    i686 pc, SUSE linux Enterprise Server 9, Kernel
2.6.5
			
			COMPILER NAME AND VERSION (AND PATCHLEVEL):
			    gcc 3.3.3 (SuSE Linux)
			
			THE $ACE_ROOT/ace/config.h FILE:
			    #include "config-linux.h"
			
			THE
$ACE_ROOT/include/makeinclude/platform_macros.GNU FILE :
			    include $ACE_ROOT/include/makeinclude/platform-
linux.GNU
			
			CONTENTS OF
$ACE_ROOT/bin/MakeProjectCreator/config/default.features
			(used by MPC when you generate your own makefiles):
			    N/A
			
			DOES THE PROBLEM AFFECT:
			    EXECUTION: ORB Initialization
			
			SYNOPSIS: Can omniORB and TAO coexist in the same
process space? 
			
			DESCRIPTION:
			Hi there,
			
			I evaluate how to port a rather big CORBA system
using omniORB
			to TAO. Because it's a rather complex system, I
started with porting one 
			CORBA servant object. It was no big efford to make
the changes to compile
			and link the code for TAO.
			
			I then tried to integrate this one TAO object into
the omniORB system.
			This system however loads CORBA servants from a
shared libraries. 
			The whole mechanism to find and load these needed
libraries, includes 
			CORBA calls (which are still served by omniORB CORBA
servants).
			As a concequence to this I end up initializing TAO
and registering
			the object within a CORBA call served by omniORB
(see attatched 
			coredump.txt), which seems to lead to a coredump.
			More specifically said, the registration of the
servant object within
			the POA, using the _this() method seems to mess up
everything.
			
			Does anyone have some hints for me, if it is a bad
idea in general to 
			use TAO and omniORB in the same adress space. Or
might the nesting of 
			TAO servant registration within the processing of
omniORB be a problem?
			Maybe someone familiar with the TAO POA can comment
on what exactly is 
			going wrong, by having a look at the coredump stack?
			
			Cheers,
			Friedhelm