| Summary: | Interface repository stores incorrect information of inherited interfaces. | ||
|---|---|---|---|
| Product: | TAO | Reporter: | Tomas Staig <tstaig> |
| Component: | Interface Repository | Assignee: | DOC Center Support List (internal) <tao-support> |
| Status: | ASSIGNED --- | ||
| Severity: | normal | CC: | bjeram |
| Priority: | P3 | ||
| Version: | 2.4.3 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Attachments: |
Modifications to IFR_Inheritance_Test to check for problem described in this ticket
TAO IFR Inheritance problem workaround |
||
This will take some time to fix. I'm not sure when I'll have time to address this, but I won't let it slip throught the cracks. I have additional information that might help to fix this issue. While I have a working workaround for the issue I don't think it is an appropriate definitive fix. In the file ACE_wrappers/TAO/orbsvcs/orbsvcs/IFRService/InterfaceDef_i.cpp the calls to: this->repo_->config ()->get_integer_value (attrs_key, "count", count); this->repo_->config ()->get_integer_value (ops_key, "count", count); Return an incorrect count value for the cases mentioned in the initial comment. This count value is used to iterate with a 'for' to obtain the list of attributes and operations which ends up in the creation of incorrect methods and attributes. I have changed this to use a while instead: while (this->repo_->config ()->enumerate_sections (attrs_key, index++, section_name) == 0) While this works some of the section_name values are either "inherited" or "ops" (I also checked for "attrs", but haven't seen any of this). If any of those words appear I just skip to the next iteration I attach the patch I'm currently successfully using, but I'd really appreciate if you can solve the problem and not the symptom (as I'm doing). Thanks, Tomas. Created attachment 1370 [details]
TAO IFR Inheritance problem workaround
This patch is in no way intended to be used as a definitive fix, it is just provided to help find the real problem and fix it.
We have been using the patch without issues for the last few years. During the time, we found an additional conflicting situation, which happens for enums under the same circumstances as the other issues.
In the patch there's the following change:
+ if(strcmp("inherited",section_name.c_str()) == 0) continue;
+ if(strcmp("ops",section_name.c_str()) == 0) continue;
+ if(strcmp("attrs",section_name.c_str()) == 0) continue;
+ this->repo_->config ()->open_section (attrs_key, section_name.c_str (), 0, attr_key);
key_queue.enqueue_tail (attr_key);
To fix this additional case, the following comparison has to be added:
+ if(strcmp("defns",section_name.c_str()) == 0) continue;
This has to be done both for 'attr_key' and for 'op_key' variables.
|
Created attachment 1362 [details] Modifications to IFR_Inheritance_Test to check for problem described in this ticket This error happens in different ways, for example when an empty interface is inherited after a non-empty interface has been inherited(a "brother" inherited before) the stored interface is incorrect. If we use these interfaces, for example: interface Base1 { void m(); }; interface Base2 { }; interface Intermediate1 : Base1 { }; interface Intermediate2 : Base2 { }; interface Intermediate3 : Base1, Base2 { }; interface Intermediate4 : Base2, Base1 { }; interface Child1 : Intermediate1 { }; interface Child2 : Intermediate2 { }; interface Child3 : Intermediate3 { }; interface Child4 : Intermediate4 { }; We obtain these undesired output: ERROR: operation Intermediate3::Base2 was not expected ERROR: operation Child1::Intermediate1 was not expected ERROR: operation Child3::Base2 was not expected ERROR: operation Child3::Intermediate3 was not expected ERROR: operation Child4::Intermediate4 was not expected A similar situation happens if we define an attribute 'a' as an attribute instead of the method 'm': ERROR: attribute Intermediate3::Base2 was not expected ERROR: attribute Child1::Intermediate1 was not expected ERROR: attribute Child3::Base2 was not expected ERROR: attribute Child3::Intermediate3 was not expected ERROR: attribute Child4::Intermediate4 was not expected I tried to find the issue and fix it myself, but couldn't find the error. I can however, give a small hint of where it could be. I first thought the problem was probably in the process of feeding the tao_ifr_service through tao_ifr. So I started looking at the method ifr_adding_visitor::visit_interface(...) in the file ifr_adding_visitor.cpp. After following the execution and looking the values to be fed I found out that the InterfaceDescription returned in the following line was corrupted: //This is done in ifr_adding_visitor::create_interface_def(...) new_def = current_scope->create_interface (node->repoID (), node->local_name()->get_string (), node->version (), bases); I went next to the definition of this create_interface in TAO_Container_i::create_interface(...) in Container_i.cpp file which calls TAO_Container_i::create_interface_i(...). In this method I'm not sure what the problem is, but it is most probably the following call: inherited_path = TAO_IFR_Service_Utils::reference_to_path(base_interfaces[i]); Alternatively I think is possible that ACE_Configuration related calls could provoke this, specially: this->repo_->config ()->set_string_value (inherited_key, stringified, inherited_path); Or the conversion of the generated path to an object reference: CORBA::Object_var obj = TAO_IFR_Service_Utils::create_objref(CORBA::dk_Interface, path.c_str(), this->repo_); Either of these calls went to internals of ACE or TAO that I didn't quite understand at the moment, so I couldn't trace the problem. I modified the test in TAO/orbsvcs/tests/InterfaceRepo/IFR_Inheritance_Test to expose the problems I presented. The problem was first encountered in ACE/TAO 5.8.1 (haven't tested older ones), but it is still present in ACE/TAO 6.0.0 and 6.0.2. I attach a diff file of the test directory, so you can reproduce the problem. Thanks, Tomas.