AW: [omniORB] Assertion failure for structure in Any of omniORB 4.1.1

[Fischer, Clemens]

Hi all,
i've seen this too while sending data to my omniORB-4.1.1-based Notification Service, but have not yet investigated further.

Regards
Clemens

-----Ursprüngliche Nachricht-----
Von: omniorb-list-bounces at omniorb-support.com [mailto:omniorb-list-bounces at omniorb-support.com] Im Auftrag von Jian Wu
Gesendet: Freitag, 12. Oktober 2007 09:33
An: omniorb-list at omniorb-support.com
Betreff: [omniORB] Assertion failure for structure in Any of omniORB 4.1.1

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.