| Summary: | Typecodes for UNIONs with multiple labels per individual case are generated incorrectly. | ||
|---|---|---|---|
| Product: | TAO | Reporter: | Simon Massey <sma> |
| Component: | IDL Compiler | Assignee: | Simon McQueen <simon.mcqueen> |
| Status: | NEW --- | ||
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 2.1.7 | ||
| Hardware: | All | ||
| OS: | Windows XP | ||
| Attachments: |
A test case for this problem.
Fix for a resource leak under error condition that the test hilights Fix for problem: TAO_IDL/be/be_visitor_typecode/union_typecode.cpp Enhanced Fix for problem: TAO_IDL/be/be_visitor_typecode/union_typecode.cpp |
||
Prismtech reference Jira TAO-69. With the original "normal" union IDL defintion:
CORBA::ORB_var orb (CORBA::ORB_init (argc, argv));
CORBA::Object_var codecFactory_obj (orb->resolve_initial_references ("CodecFactory"));
IOP::CodecFactory_var codecFactory (IOP::CodecFactory::_narrow (codecFactory_obj));
IOP::Encoding cdr_encoding;
cdr_encoding.format = IOP::ENCODING_CDR_ENCAPS;
cdr_encoding.major_version = 1;
cdr_encoding.minor_version = 2;
IOP::Codec_var codec (codecFactory->create_codec (cdr_encoding));
MultiLabelUnion mlu;
mlu.mlu_char ('4');
mlu._d (1);
CORBA::Any any;
any <<= mlu;
CORBA::OctetSeq_var messageInCDR = codec->encode (any);
CORBA::Any_ptr result = codec->decode (messageInCDR);
The above "result" is unusable as the any is corrupt as if the union had used an unknown case label and the data for the '4' is not copied into it. This is due to the $TAO_ROOT/tao/AnyTypeCode/skip.cpp in the TAO_Marshal_Union::skip (tc, InputCDR) function (lines 316-545) doesn't have the correct information from the typecode to decode the correct case. (It would also effect the append.cpp in the same way).
I think this is generated from: // TAO_IDL - Generated from // be/be_visitor_typecode/union_typecode.cpp:66 Sorry obviosuly the idl unions above should be:
union MultiLabelUnion switch (long) {
case 0:
case 1:
char mlu_char;
case 2:
double mlu_double;
};
and
union MultiLabelUnion switch (long) {
case 0:
char mlu_char;
case 1:
char mlu_char;
case 2:
double mlu_double;
};
Looks like JacOrb is actually generating the typecode correctly with duplicate members for each label as per Henning and Vinoski's statement. It's just TAO and eORB which isn't. Created attachment 1453 [details]
A test case for this problem.
Added a test case for this problem untar with tar -xzf Bug_4097_Regression.gztar
Created attachment 1454 [details]
Fix for a resource leak under error condition that the test hilights
Line 160 "empty_value" is not actually deleted by the destructor of the "replacement" so the "replacement_safety" auto_ptr is not enough to protect against memory leak of the "empty_value" under error conditions. This diff adds another auto_ptr for the "empty_value".
Problem seems to be from: be/be_visitor_typecode/union_typecode.cpp:174 TAO::be_visitor_union_typecode::visit_cases (be_union * node) see comment at line 214-216. The typecode is not getting generated with all the correct information. Created attachment 1455 [details]
Fix for problem: TAO_IDL/be/be_visitor_typecode/union_typecode.cpp
Test now passes. Typecode for multi-case labels for union type now created correctly by tao_idl compiler.
Created attachment 1456 [details]
Enhanced Fix for problem: TAO_IDL/be/be_visitor_typecode/union_typecode.cpp
Replacing the original as it had a flaw for one of the existing IDL_Tests, this enhanced version corrects that and reduces the amount of static memory required if the default type is aliased.
Reassign because Simon Massey left PT. Simon, what is the status of this? |
For example the following legal IDL union declarion: union MultiLabelUnion { case 0: case 1: char mlu_char; case 2: double mlu_double; }; Currently TAO (and a few other orbs including JacOrb and eOrb'C' eORB'C++') do not handle the typecode generation correctly for this. Only one of the above cases for the mlu_char member are dealt with in the typecode information, even though the generated (de)marshaling code correctly handles all case labels. This means that such unions sent inside anys are impossiable to decode at the receiving end if the missing case label is being used for the union it holds. When using the typecode interface functions for the above it incorrectly gives: tc->member_count () returns 2 (for the two types) tc->member_label(0), tc->member_name(0) and tc->member_type(0) returns 0, "mlu_char", and char tc->member_label(1), tc->member_name(1) and tc->member_type(1) returns 2, "mlu_double", and double The exact handling for the above is not actually dealt with in the CORBA spec as far as I can see excepting that multiple case labels for a type are perfectly valid for unions. BUT I've found a little passage detailing this in the Henning and Vinoski “Advanced CORBA Programming with C++” bilble. See page 700. (of the 16.3.2 Chapter “Type Code Parameters” page 698-700 covering “Type Code Parameters for Unions”). This states that the member_count for unions should actually be the number of case labels NOT the number of types. This would make the typecode information that needs to be generated for the above type produce: tc->member_count () returns 3 (for the the number of labels) tc->member_label(0), tc->member_name(0) and tc->member_type(0) returns 0, "mlu_char", and char tc->member_label(1), tc->member_name(1) and tc->member_type(1) returns 1, "mlu_char", and char tc->member_label(2), tc->member_name(2) and tc->member_type(2) returns 2, "mlu_double", and double This was found by a Prismtech customer who noted that inter-op with TIDorb wasn't working correctly when extracting such a union from an any as generated by TAO. As a work-a-round, if they modified the IDL for the type to: union MultiLabelUnion { case 0: char mlu_char; case 1: char mlu_char; case 2: double mlu_double; }; everything started working again, but that the normal IDL (that doesn't work) should also work.