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

Ridgway, Richard (London) Richard_Ridgway at ml.com
Thu Jun 21 10:20:10 CDT 2007


Sure, the website is omniorb.sourceforge.net, mailing list at
omniorb-list at omniorb-support.com.
Duncan Grisby is generally very helpful on the mailing list (and also I
believe offers commercial support in a similar manner to the companies
support ACE+TAO).


-----Original Message-----
From: tao-users-bounces at cse.wustl.edu
[mailto:tao-users-bounces at cse.wustl.edu] On Behalf Of Friedhelm Wolf
Sent: 21 June 2007 16:14
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
--------------------------------------------------------

This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
--------------------------------------------------------



More information about the Ace-users mailing list