[omniORB] Unbalanced POA_ptr reference counting in POA_tie class templates

Mauron, Beat (CH - MSS) Beat.Mauron at ch.meggitt.com
Tue Feb 14 12:16:38 GMT 2017


Hi,

Can you give more details about your suggested correction (which files or class)
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.



More information about the omniORB-list mailing list