Hello all,
In our project has been using omniorb 4.1.0 and it passes all our own
test suite.
When we try to migrate to new version 4.1.1, there is a assertion
failure for structures in Any for the same test suite. For all the other
types in Any the tests pass.
The interface function definition in idl is
long f_vi(
in any p1,
inout any p2,
out any p3
);
The struc definition in idl is
struct fix_bas_0d_str {
boolean bo;
char ch;
octet uc;
short sh;
unsigned short us;
long my_in;
unsigned long ui;
long lo;
unsigned long ul;
float fl;
double db;
my__n_enu_t en_n;
o_enu_t en_o;
t_enu_t en_t;
instanceid id;
timestamp ts;
};
The error appears while the python client calling function f_vi() with
this struct inside Any. The c++ server will give this output many times.
omniORB: Assertion failed. This indicates a bug in the application
using omniORB, or maybe in omniORB itself.
file: ../../../../../src/lib/omniORB/dynamic/tcParser.cc
line: 297
info: 0
However, if we make the following change of line 729-731 in tcParser.cc,
all our test cases pass without any error:
void tcParser::copyStreamToStream(const CORBA::TypeCode_ptr tc,
cdrStream& src,
cdrStream& dest) {
// if (src.unmarshal_byte_swap() == dest.marshal_byte_swap())
// fastCopyUsingTC(ToTcBase_Checked(tc), src, dest);
// else
copyUsingTC(ToTcBase_Checked(tc), src, dest);
}
Looking closer into function fastCopyUsingTC() in tcParser.cc, it has no
switch on tc_struct and goes to default line 297. Is that the source of
the error?
We also notice that tcParser.cc is exactly the same in version 4.1.0 and
4.1.1. Is it possible that the other changes in 4.1.1 make this problem
appears in the new version.
In the attachment you will see all the idl types used in Any in our test
suite. The only failure cases are:
fix_bas_0d_str
fix_def_0d_str
var_nes_0d_str
var_nes_1d_str
var_nes_2d_str
var_nes_3d_str
For var_nes_1d_uni and var_nes_2d_uni they give another error output,
which is:
omniORB: Assertion failed. This indicates a bug in the application
using omniORB, or maybe in omniORB itself.
file: ../../../../../src/lib/omniORB/dynamic/tcParser.cc
line: 297
info: 0
omniORB: From endpoint: giop:tcp:172.19.26.169:43741. Detected GIOP 1.2
protocol error in input message. giopImpl12.cc:1035. Connection is
closed
All of these failed types have one thing in common. They all has
fix_bas_0d_str or fix_def_0d_str defined inside. Moreover, these two
structs only have fixed length field defined.
Do you know what is the cause of this problem?
Best regards,
Jian Wu
--
The information contained in this communication and any attachments is confidential and may be privileged, and is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. Unless explicitly stated otherwise in the body of this communication or the attachment thereto (if any), the information is provided on an AS-IS basis without any express or implied warranties or liabilities. To the extent you are relying on this information, you are doing so at your own risk. If you are not the intended recipient, please notify the sender immediately by replying to this message and destroy all copies of this message and any attachments. ASML is neither liable for the proper and complete transmission of the information contained in this communication, nor for any delay in its receipt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tst_t.idl
Type: application/octet-stream
Size: 31614 bytes
Desc: tst_t.idl
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20071012/c61383e2/tst_t-0001.obj