[omniORB] Unbalanced POA_ptr reference counting in POA_tie class templates

[Daniel Krügler]

2017-02-14 13:16 GMT+01:00 Mauron, Beat (CH - MSS) <Beat.Mauron at ch.meggitt.com>:
> Hi,
>
> Can you give more details about your suggested correction (which files or class)

I'm talking about all tie class templates generated by the IDL
compiler. For example given a IDL interface TestCallback the following
template will be generated by the OmniOrb IDL compiler:

                template <class _omniT>
                class TestCallback_tie : public virtual TestCallback
                {
                public:
                  TestCallback_tie(_omniT& t)
                    : pd_obj(&t), pd_poa(0), pd_rel(0) {}
                  TestCallback_tie(_omniT& t, ::PortableServer::POA_ptr p)
                    : pd_obj(&t), pd_poa(p), pd_rel(0) {}
                  TestCallback_tie(_omniT* t, _CORBA_Boolean r=1)
                    : pd_obj(t), pd_poa(0), pd_rel(r) {}
                  TestCallback_tie(_omniT* t,
::PortableServer::POA_ptr p,_CORBA_Boolean r=1)
                    : pd_obj(t), pd_poa(p), pd_rel(r) {}
                  ~TestCallback_tie() {
                    if (pd_poa)  ::CORBA::release(pd_poa);
                    if (pd_rel)  delete pd_obj;
                  }

                  [...]

                private:
                  _omniT*                   pd_obj;
                  ::PortableServer::POA_ptr pd_poa;
                  _CORBA_Boolean            pd_rel;
                };

If you look at the constructors

TestCallback_tie(_omniT& t, ::PortableServer::POA_ptr p)

and

TestCallback_tie(_omniT* t, ::PortableServer::POA_ptr p,_CORBA_Boolean r=1)

you should notice that the initialization of the pd_poa member is identical to

pd_poa(p)

but the destructor performs a ref counter release:

if (pd_poa)  ::CORBA::release(pd_poa);

The release call in the destructor is correct, but what is missing
here is the call of POA::_duplicate() in both constructors.
Effectively, the current pd_poa initialization needs to be corrected
to:

pd_poa(::PortableServer::POA::_duplicate(p))

- Daniel


> Thanks
> Béat
>
> -----Original Message-----
> From: Daniel Krügler via omniORB-list [mailto:omniorb-list at omniorb-support.com]
> Sent: mardi 14 février 2017 08:54
> To: omniorb-list at omniorb-support.com
> Subject: [omniORB] Unbalanced POA_ptr reference counting in POA_tie class templates
>
> 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
>
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list
>
> This e-mail may contain confidential information and/or copyright material. This e-mail is intended for the use of the addressee only. Any unauthorized use may be unlawful. If you receive this e-mail by mistake, please advise the sender immediately by using the reply facility in your e-mail software. Information contained in and/or attached to this document may be subject to Export Control Regulations of the European Community, USA or other countries. Each recipient of this document is responsible to ensure that usage and/or transfer of any information contained in this document complies with all relevant Export Control regulations.  If you are in any doubt about the Export Control restrictions that apply to this information, please contact the sender immediately.
>
> Be aware that the contents of this e-mail may be monitored to ensure compliance with the Meggitt IT User policy.



-- 

________________________________
SavedURI :Show URLShow URLSavedURI :
SavedURI :Hide URLHide URLSavedURI :
https://mail.google.com/_/scs/mail-static/_/js/k=gmail.main.de.LEt2fN4ilLE.O/m=m_i,t,it/am=OCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt=h/d=1/rs=AItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=1395770800154https://mail.google.com/_/scs/mail-static/_/js/k=gmail.main.de.LEt2fN4ilLE.O/m=m_i,t,it/am=OCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt=h/d=1/rs=AItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=1395770800154
________________________________