[omniORB] Unbalanced POA_ptr reference counting in POA_tie class templates

[Daniel Krügler]

Hi,

We recently tried to use the OmniOrb generated POA_tie class templates
via the so-called delegation-based interface implementation approach
by additionally providing an explicit (not-null) POA instance via the
corresponding constructor. Since we used that approach we noticed
internal OmniOrb assertions during shutdown time (when the POA was
destroyed). The analysis of the problem indicated a double-destruction
attempt of the POA.

By comparing the C++03 CORBA language binding specification of the tie
class with the OmniOrb implementation we noticed a seemingly incorrect
reference counter balancing in the generated tie classes:

According to the spec, if the implementation internally hold a POA_ptr
(Or the equivalent to this), it needs to call POA::_duplicate() in the
constructor on the provided POA and in the destructor it needs to call
CORBA::release() on that hosted member. But the current OmniOrb
implementation 4.2.1 that we are using, doesn't call POA::_duplicate()
in the constructor, but still calls CORBA::release() in the
destructor.

As a workaround we have created a derived class for the tie classes
that holds another POA_ptr data member were we ensure proper lifetime
management as described by the spec, ensuring that we also override
the _default_POA() function to return our new member value instead.
>From this point on the shutdown behaviour was normal again, so I would
recommend to apply a corresponding fix (That is: Adding the missing
POA::_duplicate() in both constructors accepting a POA) to the code
generation of the POA_tie classes ensuring a properly balanced POA
reference counting internally.

Thanks,

- Daniel