[omniORB] There still exists a bug with inserting exceptions into an any !

[Jean Francois Poilpret]

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 =3D CORBA::ORB_init(argc, argv, "omniORB3");
        CORBA::Object_var obj =3D =
orb->resolve_initial_references("RootPOA");
        PortableServer::POA_var rootPoa =3D =
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 =3D
                =
rootPoa->create_id_assignment_policy(PortableServer::USER_ID);
        policies.length(1);
        policies[0] =3D =
PortableServer::IdAssignmentPolicy::_duplicate(idassign);
        PortableServer::POA_var myPoa =3D
                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 =3D =
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 <<=3D exc;
        CORBA::TypeCode_var tc =3D a.type();
        const char* p =3D tc->name();
        if (*p !=3D 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 <<=3D 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=E7ois