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-***@omniorb-support.com [mailto:omniorb-list-***@omniorb-support.com] Im Auftrag von Jian Wu
Gesendet: Freitag, 12. Oktober 2007 09:33
An: omniorb-***@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

[Fischer, Clemens]

Hi Duncan,

the problem seems to occur whenever the server-side receives an any that contains a struct which in turn contains an enum.

I've attached a small example. Just unpack, chdir to omni411-test, set OMNIORB_ROOT to your omniORB's install path and say 'make server; make client'. Then run server with -ORBendPoint ::localhost:9999 and client without args.

I'm running omniORB on Suse 10.2 with gcc 4.1.2.

Cheers
Clemens

-----Urspr?ngliche Nachricht-----
Von: omniorb-list-***@omniorb-support.com [mailto:omniorb-list-***@omniorb-support.com] Im Auftrag von Duncan Grisby
Gesendet: Sonntag, 14. Oktober 2007 17:28
An: Jian Wu
Cc: omniorb-***@omniorb-support.com
Betreff: Re: [omniORB] Assertion failure for structure in Any of omniORB 4.1.1

On Friday 12 October, "Jian Wu" wrote:

[...]

Post by Fischer, Clemens
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,
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?

No, that's not the problem. The fast copy case uses an "alignment table"
that is generated from the TypeCode. Struct TypeCodes should never
appear in an alignment table, so it's right that the switch doesn't
handle the case of tk_struct. If there is a tk_struct TypeCode in there,
it's a bug in the code that generates the alignment table.

Something helpful would be if you add a log message just before the
assertion failure to show what TypeCode kind the switch has encountered.

Post by Fischer, Clemens
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.

The code that generates the struct alignment table, in typecode.cc, has
been changed, to fix a bug related to recursive structs. That is
presumably the cause of the error, but I can't see a problem just be
reading the code.

Post by Fischer, Clemens
In the attachment you will see all the idl types used in Any in our test

Are you able to come up with a minimal test case that fails? It's very
difficult to see what's going on in that big generated IDL file. Also,
it #includes and uses types from a couple of other files that you didn't
provide. It would be really handy if you could provide code that fails,
as well as just the IDL. That will make it much easier for me to
reproduce it.

Cheers,

Duncan.
--
-- Duncan Grisby --
-- ***@grisby.org --
-- http://www.grisby.org --

_______________________________________________
omniORB-list mailing list
omniORB-***@omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: omni411-test.tar.gz
Type: application/x-gzip
Size: 1100 bytes
Desc: omni411-test.tar.gz
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20071015/2c3b869c/omni411-test.tar.bin

[Duncan Grisby]

Post by Fischer, Clemens
the problem seems to occur whenever the server-side receives an any
that contains a struct which in turn contains an enum.

Thanks. That made it obvious what the problem was. As TypeCodes are
constructed, they are marked as either complete or not. Enum TypeCodes
were incorrectly not being marked as complete. The earlier bugfix to
struct TypeCodes means that structs care if their contents are complete
or not.

The fix is really trivial. I've checked it in to CVS, and attached it
here as a patch.

Cheers,

Duncan.

-------------- next part --------------
Index: src/lib/omniORB/dynamic/typecode.cc
===================================================================
RCS file: /cvsroot/omniorb/omni/src/lib/omniORB/dynamic/Attic/typecode.cc,v
retrieving revision 1.40.2.17
diff -u -r1.40.2.17 typecode.cc
--- src/lib/omniORB/dynamic/typecode.cc 10 Jun 2007 18:43:08 -0000 1.40.2.17
+++ src/lib/omniORB/dynamic/typecode.cc 15 Oct 2007 14:06:49 -0000
@@ -3562,6 +3562,7 @@
const CORBA::EnumMemberSeq &members)
: TypeCode_base(CORBA::tk_enum)
{
+ pd_complete = 1;
pd_repoId = repositoryId;
pd_name = name;
pd_members = members;
@@ -3573,6 +3574,7 @@
TypeCode_enum::TypeCode_enum()
: TypeCode_base(CORBA::tk_enum)
{
+ pd_complete = 1;
pd_alignmentTable.setNumEntries(1);
pd_alignmentTable.addSimple(omni::ALIGN_4, 4);
}
-------------- next part --------------