Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[tao-users] "IDL:omg.org/CORBA/BAD_PARAM:1.0" ??? Help !!!

942 views
Skip to first unread message

Olivier Mascia

unread,
Jul 6, 2000, 3:00:00 AM7/6/00
to

Being an absolute beginner to ACE, TAO and CORBA (except for theory), I have
a practical problem with the following code, using ACE 5.1 / TAO 1.1 build
with C++ Builder on Win2000. Everything compiles OK, all the tests run
flawlessly. The problem must be in my code or way I compile my code.

In the following code fragment taken from my WinMain...

ACE_ini();
...
CORBA::ORB_var orb = CORBA::ORB_init(_argc, _argv);
CORBA::Object_var poa_object =
orb->resolve_initial_references("RootPOA");
PortableServer::POA_var poa =
PortableServer::POA::_narrow(poa_object);
PortableServer::POAManager_var poa_manager = poa->the_POAManager();
poa_manager->activate();

EssaisImpl Essais_;
Essais_var Essais = Essais_._this(); // <<<<< PROBLEM HERE

CORBA::String_var ior = orb->object_to_string(Essais);
std::ofstream os("essais.ior");
os << ior << std::endl;
os.close();
...

I get a CORBA exception.
The id() gives me "IDL:omg.org/CORBA/BAD_PARAM:1.0".
It happens when executing the _this() method.

I hope it will mean something to most of you !

Thanks,

---------------------------------------------------------------------
Olivier Mascia T.I.P. Group SA
o...@tipgroup.com www.tipgroup.com

Olivier Mascia

unread,
Jul 7, 2000, 3:00:00 AM7/7/00
to

I have some more info on the problem summarized below.
Having trace under debugger, the exception is thrown from the method _this
of the POA_Essais class generated by the IDL compiler. Let me quote here
that function. It looks like it is related to collocation of objetcs.

Essais* POA_Essais::_this (CORBA_Environment &ACE_TRY_ENV)
{
TAO_Stub *stub = this->_create_stub (ACE_TRY_ENV);
ACE_CHECK_RETURN (0);
if (stub->servant_orb_var ()->orb_core ()
->optimize_collocation_objects())
switch (stub->servant_orb_var ()->orb_core ()
->get_collocation_strategy())
{
case TAO_ORB_Core::THRU_POA:
{
... cut for space ...
}
case TAO_ORB_Core::DIRECT:
{
... cut for space ...
}
default:
// *** This is the source of exception ***
ACE_THROW_RETURN (CORBA::BAD_PARAM (), 0);
}
else
{
... cut for space ...
}
}

So... It all means that get_collocation_strategy() returns a constant which
is unexpected. I would have expected it to take the value
TAO_ORB_Core::THRU_POA.

I am at the start of my learning curve. I have read I can alter the default
collocation strategy by passing various command-line arguments to my server.
No matter those settings, I always fall on the above exception. What could
possibly impact the correct initialization of the ORB so that the
collocation_strategy is invalid ?

I'm sure I can track this by myself with enough time.
If only some of you had some pointers or directions for me to look at ?
I have triple checked my compiler settingsn, they look ok (compiler flags
and defines).
At least, the ACE and TAO .DLL and tests and apps did compile, link and test
ok without any problem.

---------------------------------------------------------------------
Olivier Mascia T.I.P. Group SA
o...@tipgroup.com www.tipgroup.com

Olivier Mascia

unread,
Jul 7, 2000, 3:00:00 AM7/7/00
to

Some more testing and debugging shows the collocation_strategy_ member of
TAO_ORB_Core class is not initialized (random value found), though this
initialization is done in the TAO_ORB_Core constructor. Some way or another,
I have a problem with the general initialization of the orb itself.

Aren't there special requirements for initializing the CORBA::ORB_var ?

| | ACE_ini();
| | ...
| | CORBA::ORB_var orb = CORBA::ORB_init(_argc, _argv);
| | CORBA::Object_var poa_object =
| | orb->resolve_initial_references("RootPOA");
| | PortableServer::POA_var poa =
| | PortableServer::POA::_narrow(poa_object);
| | PortableServer::POAManager_var poa_manager = poa->the_POAManager();
| | poa_manager->activate();
| |
| | EssaisImpl Essais_;
| | Essais_var Essais = Essais_._this(); // <<<<< PROBLEM HERE

Execption : "IDL:omg.org/CORBA/BAD_PARAM:1.0"

Thanks for any idea or direction to follow...

Carlos O'Ryan

unread,
Jul 7, 2000, 3:00:00 AM7/7/00
to
Hi Olivier,

>
> Some more testing and debugging shows the collocation_strategy_ member
of
> TAO_ORB_Core class is not initialized (random value found), though
this
> initialization is done in the TAO_ORB_Core constructor. Some way or
another,
> I have a problem with the general initialization of the orb itself.

In general we need the PROBLEM-REPORT-FORM to help you, otherwise we
have to guess the configuration, compiler, platform, etc. and most of
time we can hardly help.


> Aren't there special requirements for initializing the CORBA::ORB_var
?

No.

>
> | | ACE_ini();
> | | ...
> | | CORBA::ORB_var orb = CORBA::ORB_init(_argc, _argv);

The first question is: are you compiling with native exception
handling enabled? If not you should check the CORBA::Environment
argument after each call.

> | default:
> | // *** This is the source of exception ***
> | ACE_THROW_RETURN (CORBA::BAD_PARAM (), 0);
> | }
> | else
> | {
> | ... cut for space ...
> | }
> | }
> |
> | So... It all means that get_collocation_strategy() returns a
constant
> which
> | is unexpected. I would have expected it to take the value
> | TAO_ORB_Core::THRU_POA.

Why does the CORBA::ORB_init() call does not initialize the
collocation strategy? It is initialized in the constructor for the
ORB_Core class, so it should not fail. Is it possible that you are
compiling with inconsistent options, like compiling the library with
minimum CORBA enabled but your test with the option disabled? Or CORBA
Messaging?

> | I'm sure I can track this by myself with enough time.
> | If only some of you had some pointers or directions for me to look
at ?

We appretiate your efforts, but this stuff works all the time for
us, on multiple platforms and compilers. My guess is that you have some
configuration problem.

> | I have triple checked my compiler settingsn, they look ok (compiler
flags
> | and defines).
> | At least, the ACE and TAO .DLL and tests and apps did compile, link
and
> test
> | ok without any problem.

Did you run the tests in $TAO_ROOT/tests? If those work OK I would
truly suspect some incorrect or inconsistent settings for your test.

HTH


--
Carlos O'Ryan (cor...@uci.edu)
#include <std.disclaimer>
#include <cute.quote> // "Speak softly and carry a megawatt laser"

Christopher Kohlhoff

unread,
Jul 7, 2000, 3:00:00 AM7/7/00
to
Hi Olivier,

At 08:29 PM 7/7/00, Olivier Mascia wrote:
>I have triple checked my compiler settingsn, they look ok (compiler flags
>and defines).

Are you sure your compiler options are identical to those used for
compiling ACE+TAO itself? You can look in
$ACE_ROOT/include/makeinclude/compiler.bor to see these values.

Alternatively, you could update to the latest version of TAO (you indicated
you were using 1.1) where all the compiler options are taken care of
automatically. I tested your code with 1.1.4 and it ran without problems.

Cheers,
Chris


Olivier Mascia

unread,
Jul 7, 2000, 3:00:00 AM7/7/00
to

First, thanks so much for your comments Carlos.

| In general we need the PROBLEM-REPORT-FORM to help you, otherwise we
| have to guess the configuration, compiler, platform, etc. and most of
| time we can hardly help.

If I can't track this down over the week-end, I'll send such a report.
I didn't until now, because I'm convinced the problem lies in some
configuration issue on my side.
The form is to report problems with TAO. And I have a problem with *my*
code.

| The first question is: are you compiling with native exception
| handling enabled? If not you should check the CORBA::Environment
| argument after each call.

Yes, native exceptions.

| Why does the CORBA::ORB_init() call does not initialize the
| collocation strategy? It is initialized in the constructor for the
| ORB_Core class, so it should not fail. Is it possible that you are
| compiling with inconsistent options, like compiling the library with
| minimum CORBA enabled but your test with the option disabled? Or CORBA
| Messaging?

I suppose that's what happen. The ACE/TAO libraries have been compiled
following the Borland C++ Builder instructions found on
http://www.tenermerx.com/programming/corba/tao_bcb/index.html. They compiled
without a problem indeed.

| We appretiate your efforts, but this stuff works all the time for
| us, on multiple platforms and compilers. My guess is that you have some
| configuration problem.

Yes, that's my guess too.

| Did you run the tests in $TAO_ROOT/tests? If those work OK I would
| truly suspect some incorrect or inconsistent settings for your test.

They compiled and all run OK. My settings *must* be incorrect for the
compilation of my own test.

Question :
Is there somewhere a description of all compile-time defines for building
ACE/TAO and applications using it ? I see a lot of those constants for
conditional compilation, but haven't yet found the description or small
comment about all of them.

I must admit that my test case is not so simple than what I posted. The
startup is such simple. But I am trying to add some objects to a big legacy
application. So when the source file containing WinMain and the stubs and
skeletons are compiled, there are numerous include files included in
addition to those pertaining to TAO and ACE. I get no duplicate definitions
nowhere, but I now fear some conditional important for ACE/TAO might get
redefined inapropriately. My configuration problem may well be there. Some
exhaustive (or nearly) list of all conditionals used to control the
configuration of ACE/TAO would then be usefull. I'd make a cross-reference
against my legacy code to see if conflicts exist.

Again thanks for your help,

Olivier Mascia

unread,
Jul 7, 2000, 3:00:00 AM7/7/00
to

| At 08:29 PM 7/7/00, Olivier Mascia wrote:
| >I have triple checked my compiler settingsn, they look ok (compiler flags
| >and defines).
|
| Are you sure your compiler options are identical to those used for
| compiling ACE+TAO itself? You can look in
| $ACE_ROOT/include/makeinclude/compiler.bor to see these values.

Well, I suppose there are some or multiple differences that I missed.
From what I was able to diagnose by myself and what I learned from here, it
is obviously a compiler configuration problem.

I'll take a good sleep, and re-check all of that over the week-end.

| Alternatively, you could update to the latest version of TAO (you
indicated
| you were using 1.1) where all the compiler options are taken care of
| automatically. I tested your code with 1.1.4 and it ran without problems.

I wanted to start with the latest version not flagged 'beta'.
I'll upgrade a little bit later.
I'm sure the problem is on me and I have no doubt this must works with 1.1.
So I'll make it work first, then I'll move on.

Thanks so much,

Olivier Mascia

unread,
Jul 7, 2000, 3:00:00 AM7/7/00
to

FIXED.
Though I feel more like I should hide myself in some deep corner, I have to
report here why I had such problems and how it is fixed.

Yes, it was a configuration problem.
The compilation options (for the legacy application which I use as a test
bed) are set to "debug" for now. In this mode the files of that application
heavily rely on the "_DEBUG" conditional defined. But the ACE & TAO
libraries linked against are the "release" ones !

I just compiled the legacy app, with the Orb code untouched, in "release"
mode, and of course, it works like a charm. So I'll have to build the ACE &
TAO debug libraries to link against my debug builds ! That's all.

I do not yet know if the major incompatibility came from the clash on the
_DEBUG conditional or anything related to inline or not code, but at least
now, I have a hand on what I need to put close attention on.

Thanks for the time some spent trying to help me narrow the problem source !

Carlos O'Ryan

unread,
Jul 7, 2000, 3:00:00 AM7/7/00
to
Hi,

> The form is to report problems with TAO. And I have a problem with
*my*
> code.

Maybe we should change the documentation. Even if the problem is in
your code we need the information in the PROBLEM-REPORT-FORM, some
problems are platform or compiler specific and depending on what
platform the comments or suggestions can make little or no sense.

> | Did you run the tests in $TAO_ROOT/tests? If those work OK I
would
> | truly suspect some incorrect or inconsistent settings for your test.
>
> They compiled and all run OK. My settings *must* be incorrect for the
> compilation of my own test.

Can you compare the settings for your build and the tests? Is there
anything different?

> Is there somewhere a description of all compile-time defines for
building
> ACE/TAO and applications using it ?

There are a number of macros described in:

$ACE_ROOT/ace/README

and then all the comments in the config-*.h and platform_*.GNU
files.... but not much else.

> I must admit that my test case is not so simple than what I posted.
The
> startup is such simple. But I am trying to add some objects to a big
legacy
> application. So when the source file containing WinMain and the stubs
and
> skeletons are compiled, there are numerous include files included in
> addition to those pertaining to TAO and ACE.

Aha, in some platforms you must include the ACE+TAO files *before*
you include anything else, mainly because the config-*.h file sets up
configuration macros that may affect the system header files (yes I
don't like that either).

> Some
> exhaustive (or nearly) list of all conditionals used to control the
> configuration of ACE/TAO would then be usefull. I'd make a
cross-reference
> against my legacy code to see if conflicts exist.

For TAO the situation is much simpler, the macros are not platform
specific and are all documented in the $TAO_ROOT/tao/orbconf.h file, for
ACE the README file mentioned above has most of the description.

> Again thanks for your help,

No problema...

0 new messages