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

[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-bounces at omniorb-support.com [mailto:omniorb-list-bounces at omniorb-support.com] Im Auftrag von Duncan Grisby
Gesendet: Sonntag, 14. Oktober 2007 17:28
An: Jian Wu
Cc: omniorb-list at omniorb-support.com
Betreff: Re: [omniORB] Assertion failure for structure in Any of omniORB 4.1.1

On Friday 12 October, "Jian Wu" wrote:

[...]
> 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?

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.

> 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.

> In the attachment you will see all the idl types used in Any in our test
> suite. The only failure cases are:

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         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --

_______________________________________________
omniORB-list mailing list
omniORB-list at 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