[omniORB] There still exists a bug with inserting exceptions into
an any !
Ivanov, Roumen
Roumen.Ivanov@drkw.com
Fri Sep 27 13:23:00 2002
Hi all,
following up.
The exception thrown from omniORB is "INTERNAL" (probably
omniORB::INTERNAL).
Here is what ORBtraceLevel 25 ORBtraceInvocations says:
omniORB: LocateRequest to remote: root<4>
omniORB: Invoke 'getIndexVola' on remote: root<4>
Error: function to insert the user exception into an Any is not available
omniORB: throw INTERNAL from dynException.cc:52
There is no difference in the Dyn skeletons generated for WinNT and for
HPUX11.
Any explanation would be appreciated.
Regards,
Roumen
-----Original Message-----
From: Ivanov, Roumen [mailto:Roumen.Ivanov@drkw.com]
Sent: Thursday, September 26, 2002 17:51
To: 'Jean Francois Poilpret'
Cc: 'omniorb list'
Subject: RE: [omniORB] There still exists a bug with inserting
exceptions into an any !
Hi all, Hi Jean Francois,
Do you have some more info about that bug.
The problem is exactly with user exceptions.
I'm observing it in my system when it runs under HP. The bug seams to be
unix (or may be linker) specific. On Win32 I'm serializing them as usualy.
I have omniORB 3.0.2 with no patches.
And, yes, the idl-s are compiled with -Wba, and the program is linked with
the required skeletons and libomniDynamic3.
This is a loadBalancing server which receives the exception from a slave and
tries to report it before rethrowing.
Do you know whether it is corrected in some later version? (Before omniORB
4.0?)
Tomorrow I will investigate what exception exactly throws omniORB in that
case.
Regards,
Roumen
-----Original Message-----
From: Jean Francois Poilpret [mailto:jfpoilpret@hn.vnn.vn]
Sent: Tuesday, August 15, 2000 06:01
To: omniORB
Subject: [omniORB] There still exists a bug with inserting exceptions
into an any !
Hi omniORBers',
Some time ago, I reported a bug with inserting exceptions thrown by
resolve_initial_references()
not being able to be inserted into an any. This bug was corrected, but
today, I still have the same kind of bug which occurred in a similar context
(although not with resolve_initial_references).
First of all, I use omniORB 3.0 with all the patches applied.
Platform is: Linux 2.2, gcc 2.95.2 (with enable_threads), glibc 2.1
given the following sample code (I'm sorry that this sample is quite long,
but this is the smallest self-contained sample I could write showing the
bug):
// dummy.idl
interface dummy
{
void op();
};
// bug_any_exc.cc
#include <iostream>
#include "dummy.hh"
// Implementation of interface dummy
class dummy_i:public POA_dummy
{
void op() {}
};
// Main entry point
int main(int argc, char** argv)
{
try
{
// Init ORB and get RootPOA
CORBA::ORB_var orb = CORBA::ORB_init(argc, argv, "omniORB3");
CORBA::Object_var obj = orb->resolve_initial_references("RootPOA");
PortableServer::POA_var rootPoa = PortableServer::POA::_narrow(obj);
std::cerr << "After getting Root POA" << std::endl;
// Create a POA with the USER_ID policy
CORBA::PolicyList policies;
PortableServer::IdAssignmentPolicy_var idassign =
rootPoa->create_id_assignment_policy(PortableServer::USER_ID);
policies.length(1);
policies[0] =
PortableServer::IdAssignmentPolicy::_duplicate(idassign);
PortableServer::POA_var myPoa =
rootPoa->create_POA( "MyPOA",
PortableServer::POAManager::_nil(),
policies);
idassign->destroy();
std::cerr << "After creating MyPOA" << std::endl;
// Instantiate dummy implementation
dummy_i dummyImpl;
std::cerr << "After instantiating dummy impl" << std::endl;
// Now try to activate our dummy object with no oid
// NB: according to the spec, as our POA has the USER_ID policy,
// activate_object() should throw the WrongPolicy exception
PortableServer::ObjectId_var oid =
myPoa->activate_object(&dummyImpl);
std::cerr << "After activate_object()" << std::endl;
orb->destroy();
std::cerr << "After destroy()" << std::endl;
}
catch (const CORBA::SystemException& exc)
{
std::cerr << "Caught a CORBA::SystemException" << std::endl;
}
catch (const CORBA::UserException& exc)
{
std::cerr << "Caught CORBA::UserException" << std::endl;
CORBA::Any a;
a <<= exc;
CORBA::TypeCode_var tc = a.type();
const char* p = tc->name();
if (*p != 0)
std::cerr << "`" << p << "'" << std::endl;
else
std::cerr << "`" << tc->id() << "'" << std::endl;
}
catch (...)
{
std::cerr << "Caught unknown exception" << std::endl;
}
return 0;
}
I know that the activate_object() call cannot work since my POA has the
USER_ID policy (so I have to use activate_object_with_id() instead). This is
to enforce a "WrongPolicy" exception thrown at this line.
Then I catch that exception in the catch(const CORBA::UserException&){...}
block.
Then I try to insert this exception into an Any (this is to use a portable
trick described in Henning & Vinoski's book to be able to find the name of
any caught CORBA exception.
But, at the line "a <<= exc;", omniORB asserts a message and throws another
exception that aborts this sample.
When run on Linux, the output is the following:
After getting Root POA
After creating MyPOA
After instantiating dummy impl
Caught CORBA::UserException
Error: function to insert the user exception into an Any is not
available
Aborted
Of course, I used the -Wba option to compile my IDL, but this has no impact
since, the activate_object() method
is not part of my own IDL, but part of the CORE library.
Obviously, this is not critical for a production application release, since
this case should never happen, but during development and debugging stages,
it's a pity I cannot see exactly what exception was thrown (to let me know
where my bug could be !)
Cheers,
Jean-François
----------------------------------------------------------------------
If you have received this e-mail in error or wish to read our e-mail
disclaimer statement and monitoring policy, please refer to
http://www.drkw.com/disc/email/ or contact the sender.
----------------------------------------------------------------------
_______________________________________________
omniORB-list mailing list
omniORB-list@omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
----------------------------------------------------------------------
If you have received this e-mail in error or wish to read our e-mail
disclaimer statement and monitoring policy, please refer to
http://www.drkw.com/disc/email/ or contact the sender.
----------------------------------------------------------------------